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1.  INTRODUCTION 

1.1  PURPOSE 

This  paper  is  a  supplement  to  IDA  Report  R-338,  The  Role  of  Concurrent 
Engineering  in  Weapons  System  Acquisition 1  [Winn88].  It  is  provided  in  response  to 
specific  tasking  in  Amendment  3  to  IDA  Task  Order  T-B5-602,  Evaluation  of  Concurrent 
Engineering  in  Weapons  System  Acquisition,  paragraph  4.g.  It  is  based  on  information 
contained  in  [Winn88],  and  an  informal  working  paper  entitled,  “An  Examination  of 
Cause-and-Effect  Relationships  in  Concurrent  Engineering,”  which  was  provided  to  the 
sponsor  in  August  1989.  It  is  intended  to  show  a  relationship  between  the  actions  taken 
by  companies  and  the  cost,  schedule,  and  quality  improvements  cited  in  the  earlier  IDA 
report. 

1.2  AUDIENCE 

The  intended  audience  for  this  report  includes  people  who  want  to  start  using  con¬ 
current  engineering  within  their  projects  or  programs,  managers  who  are  considering  how 
to  use  concurrent  engineering,  and  research  directors  who  are  developing  programs  to 
provide  the  methods  and  technologies  needed  for  concurrent  engineering.  This  paper  is 
intended  to  help  them  understand  how  the  methods  used  in  support  of  other  concurrent 
engineering  efforts  could  be  beneficial  to  them. 

1.3  METHODOLOGY 

The  authors  used  information  gathered  in  the  earlier  phase  of  the  concurrent 
engineering  task.  They  also  conducted  follow-up  visits  with  companies  contacted  during 
the  first  phase  and  initiated  new  contacts.  They  combined  data  gathered  during  personal 
visits  and  interviews  with  information  found  in  the  professional  literature  to  form  the 
basis  for  the  conclusions  contained  herein.  The  conclusions  themselves  are  the  result  of 
the  authors’  assessment  of  the  evidence  and  their  judgement  about  its  importance. 

When  organizing  the  data  gathered  to  arrive  at  conclusions,  the  authors  used 
several  techniques  usually  associated  with  quality  improvement.  These  techniques  used 
were  relatively  simple  and  did  not  include  statistical  methods.  The  relationship  between 
actions  taken  and  results  achieved  were  studied  using  Pareto  diagrams,  cause  and  effect 


1 .  Sections  of  this  paper  are  repeated  verbatim  from  Appendix  B  of  the  original  report. 
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graphs,  and  elementary  grouping  techniques.  These  techniques  were  developed  by  Ishi- 
kawa  [Ishi82]  to  be  used  by  hourly  employees  in  factories.  There  are  seven2  such  tools  in 
all.  Use  of  these  tools  was  widely  reported  during  the  IDA  concurrent  engineering  study. 
More  advanced  statistical  methods  were  not  applied  because  the  scope  of  the  effort  did 
not  permit  design  or  conduct  controlled  experiments. 

There  are  at  least  two  perspectives  of  concurrent  engineering.  The  first  view  sees 
it  as  a  new  skill  or  at  least  a  departure  from  previous  methods  of  developing  products. 
The  second  holds  concurrent  engineering  to  be  the  collection  of  the  individual  methods  or 
techniques  that  have  been  adopted  by  companies  practicing  it.  Within  this  report,  con¬ 
current  engineering  is  defined  according  to  the  first  view,  but  the  discussion  concentrates 
on  the  individual  methods  (the  second  view).  The  individual  methods  are  the  most  easily 
recognized  external  indications  that  a  company  has  begun  to  practice  concurrent 
engineering  and  have  been  the  subjects  of  considerable  speculation  during  previous  meet¬ 
ings  with  government  and  industry  representatives.  Nevertheless,  methods  are  not,  singly 
or  in  combination,  taken  by  the  authors  as  defining  concurrent  engineering. 

For  the  purpose  of  this  paper,  concurrent  engineering  is  defined  [Winn88  p.  2]  to 
be 


a  systematic  approach  to  the  integrated,  concurrent  design  of  products  and 
their  related  processes,  including  manufacture  and  support.  This 
approach  is  intended  to  cause  the  developers,  from  the  outset,  to  consider 
all  elements  of  the  product  life  cycle  from  conception  through  disposal, 
including  quality,  cost,  schedule,  and  user  requirements. 

Additional  descriptions  of  the  general  concepts  of  concurrent  engineering  can  be  found  in 
[Winn88  or  Penn89]. 

The  philosophy  that  sets  concurrent  engineering  apart  from  traditional 
approaches  is  the  emphasis  on  viewing  activities  as  an  integrated  process.  The  president 
of  one  large  defense  contractor  observed  that  concurrent  engineering  differs  most  from 
his  company’s  previous  approach  precisely  because  of  the  new  emphasis  on  process.  The 
entire  collection  of  activities  needed  to  change  an  idea  into  a  fielded,  successful,  profit¬ 
able  product-line  is  now  viewed  as  a  single  process.  This  single  process  is  now  managed 
and  optimized  based  on  global  optimization  criteria,  not  the  optimization  standards  of  the 
different  functional  subgroups. 


2.  The  seven  tools  are  graphs,  histograms,  cause-and-effect  diagrams,  check  sheets,  Pareto  diagrams, 
control  charts,  and  scatter  diagrams. 
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Concurrent  engineering  is  basically  an  approach  for  integrating  different  activi¬ 
ties,  but  it  manifests  itself  in  the  application  of  certain  tools  and  methods.  Many  people 
who  observe  it  in  practice  have  an  easier  time  identifying  the  different  methods  or  tech¬ 
niques  (such  as  the  Ishikawa  tools)  used  than  understanding  the  underlying  integration  of 
separate  activities.  Furthermore,  although  many  of  these  methods  are  not  new  (either  in 
this  country  or  overseas),  they  seem  to  be  new  to  managers  who  are  unfamiliar  with  the 
concepts  behind  them.  Although  descriptions  of  the  techniques  which  have  been  cited 
most  often  among  companies  practicing  concurrent  engineering  are  presented  in  this 
paper,  the  reader  is  cautioned  that  use  of  these  methods  is  not,  by  itself,  sufficient  reason 
to  conclude  that  a  company  is  practicing  concurrent  engineering. 

Of  the  many  methods  associated  with  concurrent  engineering,  some  of  the  most 
striking  come  from  the  quality  community.  In  gathering  information  for  this  report,  the 
authors  found  that  quality  initiatives  are  inseparable  from  concurrent  engineering.  A  par¬ 
ticipant  at  a  recent  cost/performance  measurement  workshop  stated  that,  “.  .  .  you  can¬ 
not  achieve  TQM  [Total  Quality  Management]  without  achieving  concurrent  engineering, 
because  without  addressing  product  and  process  issues  simultaneously,  and  without  an 
ability  to  solve  the  timing  problem  in  the  funding  profiles  of  every  one  of  our  programs, 
you  can’t  achieve  [TQM].”  [Ches89  p.  181]  To  illustrate,  suppose  Company  A  decides  to 
implement  a  total  quality  program3  to  improve  the  quality  of  their  products  and  services. 
Typically,  such  a  decision  will  lead  the  company  to  examine  the  principles  of  Deming 
[Demi86]  ,  Juran  [Jura88] ,  Crosby  [Cros79]  ,  or  one  of  the  other  experts  on  quality.  Each 
expert  emphasizes  slightly  different  techniques,  but  the  Deming  approach  with  its  four¬ 
teen  obligations  of  top  mangement  is  representative  of  what  such  a  company  would  find. 
Five  of  the  fourteen  points  are  very  closely  tied  to  the  practice  of  concurrent  engineering4: 

1.  Create  constancy  of  purpose  for  improvement  of  product  and  service. 


3.  Results  of  a  survey  conducted  by  the  American  Society  for  Training  and  Development  and  reported  in 
the  October  1989  issue  of  Aerospace  Engineering  indicate  that  among  a  panel  of  Fortune  500  executives, 
57  percent  of  the  responding  companies  have  total  quality  as  a  formal  strategic  goal  and  two-thirds  of  the 
remaining  companies  expect  that  it  will  become  a  formal  goal  within  the  next  three  years.  Aerospace 
Engineering,  October  1989,  p.  4. 

4.  From  a  handout  at  a  workshop  sponsored  by  George  Washington  University.  The  complete  list:  1) 
Create  a  constancy  of  purpose.  2)  Adopt  the  new  philosophy.  3)  Cease  dependence  on  inspections  to 
achieve  quality.  4)  End  the  practice  of  awarding  business  on  the  basis  of  price  tag.  Instead  minimize  total 
cost  by  working  with  a  single  supplier.  5)  Improve  constantly  and  forever  every  process  for  planning, 
production  and  service.  6)  Institute  training  on  the  job.  7)  Adopt  and  institute  leadership.  8)  Drive  out 
fear.  9)  Break  down  barriers  between  staff  areas.  10)  Eliminate  slogans,  exhortations,  and  targets  for 
the  workforce.  11)  Eliminate  numerical  quotas  for  the  workforce  and  numerical  goals  for  management. 
12)  Remove  barriers  that  rob  people  of  pride  of  workmanship.  Eliminate  the  annual  rating  of  merit.  13) 
Institute  a  vigorous  program  of  education  and  self-improvement.  Education  is  required  for  changes  in 
management.  14)  Put  everybody  in  the  company  to  work  to  accomplish  the  transformation. 
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4.  Ei.d  the  practice  of  awarding  business  on  the  basis  of  price  tag  alone.  Instead, 
minimize  total  cost  by  working  with  a  single  supplier. 

5.  Improve  constantly  and  forever  every  process  for  planning,  production,  and  ser¬ 
vice. 

9.  Break  down  barriers  between  staff  areas. 

14.  Put  everybody  in  the  company  to  work  to  accomplish  the  transformation. 

A  company  whose  management  accepts  these  responsibilities  will  find  (if  it  is  typ¬ 
ical  of  the  companies  visited  during  this  study)  it  also  has  discovered  the  teamwork  that 
leads  to  concurrent  engineering.  The  teams,  if  they  are  sincerely  improving  their 
processes,  will  demand  that  the  company  provide  the  type  of  tools  which  are  needed  to 
support  concurrent  engineering.  People  will  also  find  that  continual  improvement  of  qual¬ 
ity  is  possible  only  when  different  functional  disciplines  cooperate. 

Conversely,  if  Company  B  decides  to  implement  concurrent  engineering  without 
first  reducing  the  variability  of  its  processes,  it  may  encounter  the  following  situation. 
Engineers  are  told  to  develop  concurrently  and  in  an  integrated  fashion  a  conceptual 
design  and  to  begin  developing  plans  for  detailed  design,  manufacture,  assembly,  and 
support  of  a  new  product.  If  each  functional  specialty  is  not  attentive  to  the  accuracy  and 
speed  demands  of  the  other  groups,  the  effort  bogs  down.  Specialists  soon  learn  that  they 
are  wasting  time  because  as  they  start  to  work  out  more  detailed  plans,  they  discover 
errors  and  inconsistencies  in  the  information  they  are  working  with  so  that  their  results 
are  wrong  and  they  must  redo  the  effort.  Instead  of  saving  time,  lowering  costs,  and 
improving  quality,  they  produce  the  opposite  result.  If  the  company  simply  automates 
existing  processes,  without  first  establishing  a  policy  for  managing  and  improving  them, 
then  the  problems  will  remain.  The  companies  visited  during  this  study  were  emphatic 
about  this  point.  Finally,  the  IDA  report  contains  considerable  information  about  quality 
initiatives  because  on  the  basis  of  many  conversations  with  representatives  of  different 
companies,  the  authors  conclude  that  successful  application  of  concurrent  engineering 
and  attention  to  improved  quality  are  inseparable. 

Methods  and  tools  are  first  presented  in  the  context  of  their  being  solutions  to 
various  high-level  problems  that  have  been  encountered  by  companies  implementing  con¬ 
current  engineering.  This  approach  was  suggested  by  a  recent  [NIST89]  workshop  on 
quality  and  productivity  methods.  The  authors  provide  one  possible  framework  that  con¬ 
forms  to  the  NIST  recommendation.  The  authors  then  demonstrate  why  other 
approaches  to  considering  the  various  methods  and  tools,  such  as  a  strict  ordering  of 
which  methods  are  “best”  or  a  quantitative  functional  relationship  of  “cause-effect” 
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relationships,  are  probably  less  important  for  now. 

1.4  SCOPE 


Concurrent  engineering  spans  the  entire  life  cycle  of  a  product  [Fabr89],  but  most 
of  the  examples  considered  to  date  are  drawn  from  the  phases  of  product  development 
that  begin  with  detailed  design  and  continue  through  initial  serial  production.  When  the 
benefits  of  using  particular  methods  are  discussed,  the  benefits  are  stated  in  terms  of 
higher  quality,  lower  cost,  and  shortened  product  development  schedules. 

The  data  contained  herein  are  not  the  result  of  controlled  experiments  nor  were 
they  gathered  through  extensive  survey.  The  authors  believe  that  sophisticated  statistical 
analyses  are  not  appropriate.  The  data  are  the  result  of  plant  visits,  reports  from  com¬ 
panies,  and  many  conversations  with  engineers  and  executives  from  participating  organi¬ 
zations.  Although  no  company  was  surveyed  in  exhaustive  detail,  representatives  from 
eighteen5  different  companies  contributed  to  this  study.  The  individuals  and  their  spon¬ 
soring  companies  represent  commercial  as  well  as  defense  sectors  in  industries  that 
include  piece-part  manufacturing,  system  design  and  assembly,  electronics,  automotive, 
airframe,  and  ship  conr'ruction.  Of  the  eighteen  companies,  eleven  provided  data  in  suf¬ 
ficient  detail  so  that  case  studies  could  be  included  in  the  previous  report.  IDA  team 
members  visited  ten  of  the  eleven. 


5.  Aerojet  Ordnance,  Allied  Signal,  AT&T,  Bell  Helicopter,  Boeing,  John  Deere,  DuPont,  General 
Dynamics,  Grumman,  Hewlett-Packard,  Honeywell,  IBM,  ITT,  Martin  Marietta,  McDonnell  Douglas, 
Newport  News  Shipbuilding,  Northrop,  and  Texas  Instruments 


2.  METHODS  AND  TECHNIQUES 

A  recent  workshop  [NIST89]  at  the  National  Institute  of  Standards  and  Technol¬ 
ogy  (NIST)  examined  topics  related  to  improvements  in  quality  and  productivity.  The 
participants  included  in  their  recommendations  the  observation  that  too  much  of  the  dis¬ 
cussion  of  changes  in  these  areas  has  addressed  techniques  instead  of  the  problems  for 
which  the  techniques  provide  a  solution.  In  response  to  such  concerns,  this  section  is 
organized  according  to  the  various  problems  which  the  methods  are  designed  to  address. 

The  first  problem  is  convincing  the  people  affected  by  the  change  that  the  status 
quo  is  not  satisfactory.  Discussions  with  people  in  several  companies  confirmed  the 
importance  of  solving  this  problem.  One  company  that  had  analyzed  its  technical  prob¬ 
lems  and  designed  a  better  way  of  solving  them  delayed  implementing  the  changes  when 
management  learned  that  employees  were  not  convinced  of  the  need  for  the  changes. 

Despite  the  importance  of  solving  the  motivational  problem,  the  previous  IDA 
study  produced  no  data  concerning  tools  or  methods  that  were  useful  in  finding  a  solution. 
The  authors  were  most  concerned  with  examining  the  methods  and  tools  that  had  been 
already  identified.  Consequently,  this  paper  will  not  address  methods  or  techniques  for 
dealing  with  the  motivation  problem. 

The  remaining  problems  are  often  encountered  by  companies  responding  to  three 

tasks: 

1.  Determine  what  the  customer  wants. 

2.  Establish  control  of  existing  processes. 

3.  Improve  the  process  so  as  to  provide  what  the  customer  wants  at  lower  cost  and  in 
less  time. 

The  apparent  simplicity  of  the  tasks  is  deceptive;  accomplishing  them  is  challeng¬ 
ing.  For  example,  one  of  the  companies  visited  related  how  it  wanted  to  start  its  improve¬ 
ment  by  first  examining  the  existing  process  and  then  analyzing  it  to  find  out  how  it  could 
be  improved.  When  writing  down  what  employees  actually  did,  the  company  discovered 
so  much  confusion  that  management  could  not  accurately  describe  the  process.  Instead, 
management  decided  to  describe  the  process  as  they  thought  it  should  be.  Having 
described  an  ideal  process,  they  could  compare  it  with  people’s  daily  activity.  In  private 


conversations,  workshop  participants  confided  that  many  companies  do  not  have  well- 
defined  processes  for  most  of  their  critical  product  development  activities. 

2.1  DETERMINE  WHAT  THE  CUSTOMER  WANTS 

As  companies  begin  to  view  a  process  as  a  collection  of  activities,  they  often 
develop  a  concept  of  internal  and  external  customers.  An  external  customer  is  the  per¬ 
son  who  has  the  money  and  who  may  be  persuaded  to  exchange  that  money  for  products 
and  services.  Each  employee  views  the  internal  customer  as  follows:  “My  internal  custo¬ 
mer  is  the  co-worker  who  accepts  goods  or  services  from  me  and  adds  additional  value  to 
them  before  they  are  delivered  to  the  external  customer.” 

Satisfying  the  internal  customer  is  a  critical  item,  but  it  is  so  closely  associated 
with  the  concept  of  process  definition  that  further  discussion  of  this  item  will  be  deferred 
until  Section  2.2  which  deals  with  process  control. 

To  satisfy  the  external  customer,  the  first  requirement  is  to  capture  the  “voice  of 
the  customer”  (VOC)  in  terms  that  the  engineer  can  understand.  This  is  not  the  same  as 
translating  the  engineer’s  concept  of  the  need  into  a  presentation  intended  to  arouse  the 
customer’s  desire  for  a  better  system.  During  the  several  workshops  that  were  part  of  this 
task,  participants  clearly  voiced  the  opinion  that  capturing  the  VOC  is  both  necessary 
and  difficult. 

Multifunction  teams  may  be  used  to  capture  the  VOC  and  representatives  of 
marketing  will  usually  take  the  lead  role.  Surveys  may  be  used  at  this  stage.  Addition¬ 
ally,  the  value  of  sending  the  engineer  out  to  the  customer  should  not  be  overlooked.  The 
“Blue  Two”  program  sponsored  by  the  Air  Force  allows  engineers  to  spend  time  in  the 
field  observing  maintenance  operations  on  fielded  systems.  Several  companies  that  parti¬ 
cipated  in  this  program  report  that  it  is  an  excellent  vehicle  for  communicating  some  of 
the  user’s  needs  to  the  engineer.  At  least  one  company  is  conducting  supportability 
awareness  training  for  designers  who  must  perform  maintenance  tasks  while  wearing 
chemical  warfare  protective  suits. 

Another  technique  for  capturing  the  user’s  requirements  and  mapping  them  into 
product  and  process  parameters  is  called  quality  function  deployment  (QFD).  QFD  ori¬ 
ginated  in  Japan  and  has  been  practiced  there  since  the  mid-1970s.  It  consists  of  tech¬ 
niques  [King87]  for  creating  and  completing  a  series  of  matrices  showing  the  association 
between  specific  features  of  a  product  and  statements  representing  the  VOC.  It  is  taught 
in  several  versions,  notably  Macabe’s  four  matrices  showing  product  planning,  part 
deployment,  process  planning,  and  production  planning;  Fukahara’s  House  of  Quality 
approach;  and  Akao’s  matrix  of  matrices. 
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QFD  uses  teamwork  and  creative  “brainstorming”  as  well  as  market  research  to 
identify  customer  demands  and  design  parameters.  The  correlation  between  the 
demands  and  the  design  parameters  is  ranked  and  normalized.  Parameters  of  competi¬ 
tor’s  products  are  also  identified  and  ranked.  The  top-down  design  process  continues  as 
functions,  mechanisms,  failure  modes,  parts  and  subassemblies,  new  concepts,  and  criti¬ 
cal  manufacturing  steps  are  identified  and  traced  to  critical  customer  demands  and  com¬ 
petitor’s  products.  Matrices  are  a  means  of  recording  the  information  to  show  correla¬ 
tions.  The  customer  demands  are  often  used  to  distinguish  the  rows  of  a  matrix  and  pro¬ 
duct  features  are  listed  for  the  columns.  Marks  in  the  entry  where  rows  and  columns 
intersect  are  used  to  show  how  product  features  help  to  satisfy  the  customer  needs.  Posi¬ 
tive  and  negative  correlations  among  the  product  features  are  given  in  a  triangular  table 
above  the  matrix.  The  triangular  table,  atop  the  matrix  resembles  a  roof,  hence  the  term 
“house  of  quality”.  Figure  1  shows  an  example  of  a  “house  of  quality”. 

One  of  the  reported  advantages  of  using  QFD  is  that  it  reduces  changes  as  a 
design  enters  production  and  decreases  the  time  needed  to  get  a  design  into  production. 
Hauser  [Haus88]  reports  the  case  of  a  Japanese  automaker  using  QFD  who  reported 
reducing  start-up  costs  by  20  percent  in  1977,  by  38  percent  in  1978,  and  by  61  percent  in 
1984  when  compared  to  its  experience  before  using  QFD.  One  of  this  company’s  sup¬ 
pliers  reported  reducing  the  number  of  engineering  changes  during  production  deploy¬ 
ment  by  more  than  half. 

Some  U.S.  companies  have  developed  techniques  for  establishing  the  require¬ 
ment  and  translating  it  into  product  features.  Responding  to  the  strong  guidance  con¬ 
tained  in  R&M  2000  [Unit87],  one  aerospace  company  recently  formed  a  multifunction 
task  team  for  the  SRAM  II  competition  [Winn88  p.  102].  Using  locally  derived  natural 
work  groups  they  translated  reliability  and  maintainability  requirements  (topics  that  had 
been  traditionally  viewed  by  many  engineers  as  “emotional  issues”)  into  identifiable  and 
measurable  design  characteristics.  Another  company  is  reported  to  have  created  a  spe¬ 
cial  facility  where  potential  customers  can  validate  their  requirements  in  a  system  that  is 
designed  to  capture  and  compare  needs  independently  of  the  rank  or  seniority  of  the  pro¬ 
ponent  of  a  particular  statement. 

Despite  the  substantial  benefits  that  QFD  appears  to  offer  in  the  design  of  com¬ 
plex  systems  such  as  military  systems,  its  application  to  such  tasks  has  not  been  publically 
reported.6  Only  four  of  the  companies  visited  during  this  study  reported  using  QFD.  At 
least  one  executive  of  a  leading  aerospace  company  characterizes  QFD  as  a  grossly  sim¬ 
plified  application  of  the  principles  of  system  engineering. 


6.  The  authors  are  aware  of  an  application  of  QFD  to  the  Advanced  Launch  System,  but  have  not  seen  it 
reported. 
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Figure  1.  The  House  of  Quality 
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Whatever  methods  or  techniques  are  used,  the  importance  of  determining  the 
customer’s  requirements  is  shared  by  the  majority  of  the  participants  in  this  study. 

2.2  ESTABLISH  CONTROL  OF  EXISTING  PROCESSES 

2.2.1  Defining  the  Process 

The  first  challenge  for  management  is  to  adopt  the  view  of  their  activities  as 
processes.  The  concept  is  applied  at  different  levels  of  granularity.  For  example,  at  one 
level  the  construction  of  an  entire  ship  might  be  viewed  as  a  process,  whereas  at  another 
level,  a  process  might  consist  of  preparing  specifications  for  the  placement  of  electrical 
cables  within  a  ship’s  compartment.  A  process7  can  be  an  engineering  task,  a  manufac¬ 
turing  task,  or  an  administrative  task. 

The  methods  used  to  define  and  describe  a  process  include  flow  charts,  brain¬ 
storming,  and  computer-aided  modeling.  The  Department  of  Defense  (DoD)  has  several 
standards  which  describe  processes  for  producing  weapons  systems,  computer  software, 
or  various  supporting  studies. 

Figure  2,  provided  by  an  AT&T  employee  8  who  participated  in  the  concurrent 
engineering  workshops,  shows  a  process  as  a  “black  box.”  It  depicts  the  relationship 
among  a  process,  the  supplier,  and  the  customer.  In  the  figure,  the  internal  structure,  such 
as  control  points,  controls,  and  measurement  points,  are  suppressed.9 

The  concept  of  a  “process”  is  not  new.  Each  company  contacted  has  historically 
defined  various  steps  to  be  performed  in  the  production  process.  King  [King87]  traces  the 
science  of  describing  processes  to  Frederick  Taylor’s  studies  of  manufacturing  in  the  early 
1900s.  Engineers,  particularly  industrial  engineers,  designed  procedures  used  in 
manufacturing  processes.  Once  these  procedures  were  translated  into  steps  that  the 
supervisors  and  workers  could  understand,  the  task  of  managing  and  improving  the  pro¬ 
cess  became  feasible. 

Deming’s  concept  of  operational  definitions  [Demi86]  has  been  used  to  determine 
i  whether  the  description  of  a  process  is  clear  and  unambiguous.  Operational  definitions 


7.  If  a  company  has  not  previously  considered  that  activities  are  viewed  as  processes  and  they  wish  to  learn 
more  about  this  concept,  then  there  are  several  good  sources  of  information.  During  this  study,  the  IDA 
team  found  that  AT&T,  IBM,  and  Hewlett-Packard  had  remarkably  similar  programs  for  dealing  with  the 
concept  of  process  mangement.  The  AT&T  approach,  called  “Process  Quality  Management  & 

'  Improvement”  (PQMI),  is  described  in  a  set  of  guidelines  that  include  step-by-step  procedures  for 

establishing  process  control.  PQMI  is  described  in  Roger  Ackerman,  Roberta  Coleman,  Elias  Leger, 
and  John  MacDorman,  Process  Quality  Management  and  Improvement  Guidelines,  Publication  Center, 
AT&T  Bell  Laboratories  (1987). 

8.  A  similar  figure  appears  in  Roger  Ackerman,  op.  cit.  p.  8. 

9.  Processes  have  internal  structure,  control  points,  and  measurement  points,  but  these  details  are 
addressed  when  the  detailed  implementation  of  the  process  is  described. 
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Figure  2.  The  Process  Model 
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tell  the  workers  what  is  to  be  done  in  terms  that  provide  a  way  to  verify  whether  or  not  the 
procedure  is  correctly  followed. 

The  adoption  of  formally  specified  steps  for  the  design  process  has  been  a  more 
recent  development.  The  design  process  is  more  difficult  to  describe  because  it  involves 
creative  activity  and,  when  implemented,  it  varies  considerably  within  and  among  com¬ 
panies.  Because  design  has  been  perceived  as  an  inherently  creative  process,  some  prac¬ 
titioners  resist  reducing  the  process  to  anything  that  might  resemble  mechanical  pro¬ 
cedure.  In  some  instances  [Nevi89]  insufficient  knowledge  and  tools  for  manufacturing 
design,  lack  of  accurate  data  on  field  failure  modes,  and  inadequate  performance  models 
of  the  product  and  production  systems  hinder  development  of  better  models  of  the  design 
process.  Although  tools  to  support  product  design  synthesis  and  analysis  (at  least  parts 
thereof)  are  available,  describing  a  process  for  concurrently  designing  the  product  and  its 
production  process  (much  less  its  support  system)  is  a  formidable  challenge. 

Despite  the  obstacles,  both  government  and  industry  have  made  progress  in  dis¬ 
covering  better  design  processes.  The  DoD  and  the  Services  have  provided  some  gui¬ 
dance  in  DoD  4245.7-M,  Transition  from  Development  to  Production,  NAVSO  P-6071 
Best  Practices,  and  USAF  R&M  2000  Process.  The  research  community  has  several  ini¬ 
tiatives  (e.g.,[Merc87  and  DARP87]  )  for  improving  productivity  and  many  of  these  are 
concerned  with  the  problem  of  improving  the  design  process. 

During  this  study,  process  management  was  mentioned  seven  times  (among 
seventy-five  total  citations  of  some  method  or  tool)  as  a  factor  in  improving  quality  or  pro¬ 
ductivity,  making  it  one  of  the  most  frequently  mentioned  factors.  One  company  reported 
immediate  benefits  from  the  effort  of  establishing  the  process.  They  found  that  much  of 
the  work  they  had  been  performing  was  entirely  unnecessary. 

2.2.2  Measure  Process  Characteristics 

Once  a  process  has  been  designed,  the  person  responsible  for  improving  it  deter¬ 
mines  which  characteristics  are  important  and  how  they  are  to  be  measured.  The  selec¬ 
tion  of  the  correct  characteristics  is  an  important  matter  and  is  generally  the  result  of  con¬ 
sultation  with  others  who  are  familiar  with  a  process,  its  customers,  or  its  suppliers. 

If  possible,  continuous  characteristics  are  superior  to  simple  pass-fail  measures. 
For  example,  the  observed  diameter  of  a  drive  shaft  is  a  better  measure  than  just  noting 
whether  the  diameter  was  within  the  specification.  The  actual  diameter  would  be  a  better 
indicator  because  it  provides  information  that  might  indicate  one  cause  for  items  that  are 
too  small  and  another  for  those  that  are  too  large. 
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Selecting  appropriate  characteristics  and  deciding  how  to  measure  them  is  partic¬ 
ularly  challenging  for  white-collar  processes.  Some  companies  are  attempting  to  measure 
such  processes  as  software  development,  purchasing,  billing,  and  product  design.  These 
efforts  are  less  mature  than  those  in  manufacturing,  yet  the  expected  payoffs  are  substan¬ 
tial  and  the  number  of  companies  involved  seems  to  be  increasing. 

2.2.3  Bring  the  Process  Under  Control 

A  process  is  said  to  be  “under  control”  if  it  produces  output  with  consistent  regu¬ 
larity.  The  metric  of  regularity  differs  for  various  applications.  For  example,  the  meas¬ 
ure  might  be  the  time  to  produce  a  product,  the  weight  of  an  object,  or  some  other  charac¬ 
teristic  that  is  important  to  the  process’  customers.  Whatever  metric  is  chosen,  a  process 
that  is  under  control  will  produce  products  whose  measured  values  vary  within  a  predict¬ 
able  range. 

An  observer  who  is  willing  to  perform  sufficiently  precise  measurements  will 
always  find  variability  among  products  produced  by  a  process.  Wheeler  [Whee86]  relates 
the  maturation  of  the  awareness  of  the  role  of  variation  in  process  measurement  and 
credits  Waltef  Shewart  and  W.  Edwards  Deming  with  important  contributions  in  under¬ 
standing  that  observed  variation  may  be  the  result  of  controlled  or  uncontrolled 
processes.  When  the  measured  variation  of  a  process  can  be  explained  by  the  assumption 
that  the  underlying  probability  distribution  of  the  measured  characteristic  is  fixed  (identi¬ 
cal,  independent  distribution),  then  the  process  is  said  to  be  controlled. 

Statistical  Process  Control  (SPC)  is  one  of  the  most  widely  use  tools  for  determin¬ 
ing  whether  observed  variation  is  the  result  of  normal  fluctuation  of  a  controlled  process 
or  the  result  of  some  special,  uncontrolled  cause. 

SPC  assumes  that  measured  characteristics  of  stable  processes  will  have  a  com¬ 
mon  distribution  (in  a  probabilistic  sense).  That  is,  different  sample  groups  of  the  pro¬ 
duct  from  the  process  will  have  the  identical  statistical  distribution  of  the  characteristic. 

Statistical  process  control  selects  sample  groups  and  conducts  simple  statistical 
tests  to  verify  the  hypothesis.  As  long  as  the  tests  do  not  show  that  samples  have  different 
distributions,  one  assumes  that  the  process  is  stable  and  concentrates  on  incremental 
improvements  for  the  process. 

If  a  test  indicates  that  the  distributions  are  not  identical,  then  one  looks  for  the 
special  causes  of  variability.  In  addition  to  statistical  process  control  charts,  Pareto 
diagrams,  cause  and  effect  diagrams,  and  PERT  charts  are  used  to  find  special  causes  of 
variability.  When  such  causes  are  found,  they  are  eliminated.  This  algorithm  is  repeated 
until  the  process  becomes  stable.  When  a  process  is  stable,  further  improvement  can  only 
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be  achieved  by  changing  the  process. 

There  are  many  excellent  texts  describing  SPC  and  a  partial  listing  can  be  found 
in  [Penn89].  The  American  National  Standards  Institute  guide  [ANSI85]  is  a  good  place 
to  start. 

During  the  EDA  concurrent  engineering  study,  process  management  and  use  of 
SPC  were  the  most  frequently  mentioned  tools.  Tools  (or  methods)  were  mentioned  a 
total  of  seventy-five  times  in  case  studies  in  [Winn88];  of  these  citations,  fourteen  men¬ 
tioned  use  of  SPC  or  process  management  as  part  of  a  concurrent  engineering  or  TQM 
program. 

Managers  in  the  United  States  and  Japan  have  used  statistical  techniques  to 
measure  performance  and  they  have  implemented  management  techniques  that  are  con¬ 
sistent  with  Shewhart’s  and  Deming’s  concepts  about  variation  in  processes.  The  reported 
results  have  been  reduced  product  variability,  improved  product  quality,  and  reduced  cost 
of  nonproductive  activities  such  as  inspection  and  rework.  Benefits  of  establishing  con¬ 
trol  of  a  process  have  been  reported  as  about  30  percent  cost  savings  through  improved 
quality. 

A  stable  process  that  yields  products  which  satisfy  the  customer’s  needs  may,  at 
some  time,  become  unstable.  Instability  may  arise  from  special  causes  as  previously 
noted.  Continued  monitoring  of  the  process  through  statistical  process  control  can  detect 
the  transition  to  an  unstable  state;  hence  management  may  infer  the  presence  of  special 
causes.  A  process  that  continues  to  pass  the  tests  isn’t  always  a  stable  process,  but  the 
probability  is  very  small  that  a  unstable  or  chaotic  process  will  continue  to  produce  output 
that  satisfies  SPC  criteria. 

Several  different  charts  are  used  in  SPC  for  conducting  these  tests.  When  the 
value  of  the  characteristic  can  be  measured,  the  x  and  R  charts  are  used;  when  the  frac¬ 
tion  of  defective  products  is  the  characteristic  being  measured,  the  p  chart  is  used;  when 
the  overall  number  of  defects  is  being  measured,  the  c  chart  is  used;  and  when  the  overall 
number  of  defects  per  unit  is  measured,  the  u  chart  is  used.  Use  of  these  charts  is 
explained  in  [ANSI85]. 

Hayes  [Haye88]  describes  four  increasing  levels  of  process  control:  reactive, 
preventive,  progressive,  and  dynamic.  Reactive  and  preventive  control  deal,  respec¬ 
tively,  with  detecting  abnormal  variation  and  preventing  its  repetition.  Progressive  con¬ 
trol  seeks  to  improve  the  process  so  as  to  reduce  variation  while  dynamic  control  allows 
the  company  to  alternate  among  several  processes  while  maintaining  progressive  control 
on  each.  Concurrent  engineering  requires  all  four  levels. 
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In  addition  to  SPC,  other  statistical  tools  are  available  for  evaluating  processes. 
In  the  late  1950s,  Page  [Page54]  and  Barnard  [Barn59]  introduced  Cumulative  Sum 
Charts  (CUSUM)  which  respond  more  quickly  to  change  in  mean  level.  (DuPont  is 
currently  using  more  than  15,000  of  these  charts.)  Hunter  [Hunt86]  describes  a  technique 
for  maintaining  control  charts  that  can  be  used  as  a  predictive  tool.  The  technique, 
exponentially  weighted  moving  average  (EWMA),  is  a  statistic  that  gives  less  and  less 
weight  to  older  data.  A  plotted  point  on  an  EWMA  chart  can  be  given  a  memory  that 
controls  the  rate  at  which  its  importance  is  diminished.  Control  limits  on  the  predicted 
values  are  used  to  show  when  the  predictions  become  unreliable  and  preventive  action 
can  be  taken. 

Taguchi  [Tagu86  p.  88]  outlines  four  steps  to  achieving  on-line  process  control:  1) 
optimize  the  measurement  interval;  2)  from  the  measured  value,  predict  the  mean  charac¬ 
teristic  value  during  the  next  interval;  3)  determine  the  optimum  correction  for  differ¬ 
ences  between  the  predicted  value  and  the  target  value;  and  4)  change  the  signal  value  to 
achieve  the  desired  correction.  He  provides  recommended  formulae  for  determining  the 
optimum  correction  interval,  the  prediction  of  the  characteristic  value,  and  the  amount  of 
correction. 

2.3  IMPROVE  THE  PROCESS 

After  a  company  gains  an  understanding  of  its  customer’s  requirements  and 
establishes  stable  processes  for  producing  goods  and  services,  it  is  ready  to  enter  the  first 
phase  of  concurrent  engineering:  providing  early  consideration  of  downstream  factors 
during  early  design.  This  phase  can  be  accomplished  using  some  combination  of  four 
techniques:  expanding  the  use  of  teams,  improving  design  evaluation  tools,  developing 
design  synthesis  aids,  and  careful  application  of  standardization. 

2.3.1  Remove  Cross-functional  Barriers 

Multifunction  teams  are  one  method  of  facilitating  the  optimization  of  all  impor¬ 
tant  measures  of  a  product’s  function — performance,  producibility,  ease  of  maintenance, 
reliability,  cost,  and  quality.  Management  forms  and  joins  a  team  whose  members  have 
specialized  knowledge  in  different  portions  of  a  product’s  life  cycle  to  concurrently 
engineer  both  the  product  and  the  downstream  processes  for  production  and  support. 
Involvement  of  these  people  in  the  design,  particularly  in  the  early  stages,  has  been  shown 
to  reduce  the  time  for  total  product  realization.  For  example,  the  participation  of 
representatives  of  the  manufacturing  or  production  branch  has  resulted  in  designs  that 
can  be  produced  with  fewer  modifications. 
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Use  of  multifunction  teams  does  not  imply  a  need  for  abolishing  existing  func¬ 
tional  specialties,  however,  some  reorganization  may  accompany  their  introduction.  One 
company  had  a  special  facility,  called  the  prototype  shop,  whose  function  was  the  fabrica¬ 
tion  of  prototype  products,  but  they  found  that  procedures  used  in  the  prototype  shop  did 
not  adequately  predict  production  problems.  Consequently,  this  company  abolished  the 
prototype  shop  and  began  building  prototypes  in  the  main  factory  using  production  work¬ 
ers,  machines,  and  prodedures.  The  change  helped  to  involve  production  personnel  in 
the  development  process  at  an  earlier  stage. 

Formation  of  the  multifunction  teams  varies  among  different  companies.  Some 
organizations  form  process-oriented  multifunction  teams,  and  others  product-oriented 
multifunction  teams.  Membership  on  the  teams  may  remain  fixed  or  it  may  vary  over  the 
life  of  a  product.  Teams  are  usually  co-located,  but  the  location  can  change  as  a  product 
moves  from  design  to  production.  Because  personal  communication  is  such  an  important 
feature  of  this  method,  the  teams  are  usually  small  (fewer  than  12  people),  but  some  com¬ 
panies  are  developing  “teams  of  teams”.  Multifunction  teams  have  been  used  to  some 
extent  on  weapons  systems  for  at  least  the  last  15  years.10 

Seifert  [Seif88]  reports  that  teamwork  was  evaluated  by  the  participants  as  being 
the  most  important  factor  in  one  large  company’s  successful  productivity  improvement 
program.  Whitney  [Whit88  p.  85]  calls  multifunctional  teams  the  “most  effective  way  to 
cut  through  barriers  to  good  design.”  More  companies  reported  using  multifunctional 
teams  than  reported  using  any  other  single  method.  Multifunction  teams  were  the  second 
most  frequently  cited  technique  in  [Winn88].  Their  use  was  mentioned  nine  times  (out  of 
seventy-five  citations)  as  a  method  which  contributed  to  cost,  quality,  and  schedule 
improvement. 

In  some  organizations,  team  members  who  represent  production  divisions  are 
selected  directly  from  those  divisions.  Other  companies  have  created  a  new  specialist, 
the  producibility  engineer  who  participates  with  the  design  team.  One  company  using 
such  a  specialist  said  that  communication  skills  were  one  of  the  most  important  qualities 
for  a  person  to  be  considered  for  such  a  position. 

A  common  observation  is  that  use  of  multifunction  teams  improves  the  ability  of 
designers  to  create  subsequent  designs  that  incorporate  from  the  start  features  reflecting 
down-stream  considerations. 


10.  Multifunction  task  teams  were  used  to  design  the  F-15. 
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2.3.2  Evaluate  Downstream  Implications  of  a  Design 

As  companies  bring  together  people  from  different  disciplines  to  practice  con¬ 
current  engineering,  the  team  members  quickly  realize  the  need  for  various  members  to 
work  at  comparable  speeds.  One  aerospace  company  reported  that  when  it  tried  to 
include  more  rigorous  treatment  of  reliability  and  maintainability  features  during  concept 
development,  the  reliability  and  support  engineers  could  not  work  as  fast  as  the  other 
engineers.  The  aerodynamic  and  structural  engineers,  for  example,  could  rapidly  evalu¬ 
ate  the  implications  of  different  design  alternatives  while  the  logisticians  were  restricted 
to  manual  calculation  to  determine  the  effects  of  different  alternatives.  Realizing  that  a 
faster  response  was  needed,  the  reliability  and  support  specialists  determined  that  they 
could  respond  more  quickly  if  they  were  provided  with  tools  that  supported  faster  ana¬ 
lyses.  To  allow  the  support  specialists  to  keep  up  with  the  other  team  members,  the  com¬ 
pany  developed  a  set  of  computer-based  evaluation  tools  that  estimated  the  maintenance 
and  support  implications  of  important  design  features.  With  the  new  tools,  the  team  was 
able  to  develop  a  design  that  not  only  met  the  reliability  and  maintainability  requirements 
but  also  could  be  produced  for  significantly  less  than  their  previous  designs.  In  this  case, 
the  faster  evaluation  tools  were  a  response  to  the  realization  by  certain  functional  special¬ 
ists  that  a  new  mode  of  working  was  needed. 

The  particular  aspect  of  a  design  that  will  be  evaluated  may  differ  according  to 
the  product  technology.  Examples  of  validation  tools  discussed  during  this  study  include 
computer-aided  timing  verification,  logic  analyzers,  fault  simulators  and  analyzers  for 
electronic  circuits  plus  thermal  analysis  tools,  assembly  and  manufacturability  analysis 
tools,  and  structural,  reliability,  and  maintainability  analysis  tools  for  mechanical  and 
aerospace  products. 

Fault  tree  analysis,  reliability  and  maintainability  assessments,  and  failure  mode 
effects  analyses  are  examples  of  tasks  that  have  traditionally  been  performed  during  pro¬ 
duct  development.  Concurrent  engineering  seeks  to  bring  the  knowledge  of  the  expert' 
who  perform  these  studies  upstream  in  the  design  process  so  that  these  and  other  factors 
will  be  considered  from  the  outset.  Computer-based  tools  allow  these  experts  to  develop 
quantitative  assessments  of  alternative  configurations  as  they  participate  in  early  discus¬ 
sions  of  the  design. 

Design  evaluation  tools  were  mentioned  by  seven  of  ten  companies  visited  during 
this  study.  One  recent  survey  [IIE89  p.  80]  reports  that  over  80  percent  of  the  responding 
companies  find  that  computer-aided  design  tools  improve  profitability  and  a  similar 
number  intend  to  expand  their  use  of  such  systems  during  1990. 
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2.3.3  Apply  Design  Rules 


Newton  and  Sangiovanni-Vincentelli  [Newt86]  in  their  survey  of  design  automa¬ 
tion  tools,  identify  three  classes  of  tools:  design  synthesis,  design  verification,  and  design 
management.  Use  of  design  rules  to  create  a  design  is  an  example  of  a  design  synthesis 
method.  The  rules  can  be  manual  such  as  workbooks  with  design  practices  for  a  particu¬ 
lar  company  01  they  can  be  included  in  the  computer-aided  design  tools  themselves.  In 
digital  electronic  design,  level-sensitive  scan  design  (LSSD)  and  built-in  logic  block  obser¬ 
vation  (BILBO)  are  examples  of  rules  that  will  result  in  designs  that  are  more  easily 
tested.  In  mechanical  design  the  use  of  group  technology  can  provide  designs  that  can  be 
manufactured  more  easily  in  existing  work-cells. 

One  of  the  most  successful  examples  of  design  rules  is  the  Design  for  Assembly 
(DFA)  software  tools  provided  by  Boothroyd  and  Dewhurst  Inc.  [Boot85].  Use  of  DFA 
has  been  credited  with  savings  of  billions  of  dollars  at  several  companies,  but  in  this 
study,  only  one  company  reported  DFA  as  one  of  the  methods  included  in  their  con¬ 
current  engineering  program. 

Among  ten  sites  visited,  five  reported  use  of  some  degree  of  design  rules  as  part 
of  their  design  process.  The  potential  advantages  of  using  design  rules  include  the 
assurance  that  designs  will  be  testable,  can  be  manufactured  with  existing  equipment,  will 
be  free  of  known  defects,  and  can  be  assembled  inexpensively.  These  advantages  provide 
for  smoother  transitions  at  key  points,  thereby  saving  time  and  improving  the  quality  of 
the  final  product. 

2.3.4  Promote  Standardization 

Standardization  is  not  normally  associated  with  concurrent  engineering,  but  the 
development  of  databases  of  standardized  parts  was  cited  by  several  companies  as  an 
element  in  their  concurrent  engineering  program.  As  the  number  of  unique  parts  used  in 
designs  decreased,  purchasing,  manufacturing,  and  design  tasks  were  simplified.  These 
companies  ensured  that  the  process  of  selecting  and  approving  parts  for  entry  into  and 
retention  in  the  database  of  approved  parts  was  one  which  involved  representatives  of 
several  functional  groups.  Thus,  application  of  standardization  was  an  important  tool  for 
improving  certain  white  collar  processes  in  these  companies. 

2.3.5  Use  Integrating  Technologies 

Within  the  class  of  integrating  technologies,  two  are  of  great  importance: 
environment  frameworks  and  description  languages.  The  first  holds  the  possibility  of  ena¬ 
bling  a  process  of  evolvable,  tailorable,  and  universal  automated  tool  integration.  The 
second  holds  the  possibility  of  standardized,  automated  communication  of  product 


designs. 

A  design  is  created  and  refined  over  some  interval.  The  process  of  creating  a 
design  and  recording  it  as  the  design  includes  some  amount  of  trial-and-error  experimen¬ 
tation.  Different  alternatives  are  tried  and  discarded  until  a  solution  is  achieved.  One 
challenge  of  design  management  is  that  the  process  must  allow  freedom  for  the  engineer 
to  try  new  alternatives  while  maintaining  control  of  who  is  allowed  to  alter  the  design  and 
when  they  are  allowed  to  do  so.  Procedures  are  also  needed  to  select  one  version  of  the 
the  several  options  being  evaluated  and  to  designate  it  as  the  design. 

Additional  work  is  needed  to  develop  common  standards  for  representing 
engineering  information.  Several  workshop  participants  described  the  DoD  Computer- 
aided  Acquisition  and  Logistics  Support  (CALS)  initiative  and  the  Product  Data 
Exchange  Specification  (PDES)  effort  as  very  promising  programs  in  this  area.  Stan¬ 
dardization  efforts  are  also  being  conducted  among  international  bodies.  For  example, 
the  International  Standards  Organization  Technical  Committee  184,  Subcommittee  4, 
Working  Group  l(ISO  TC184/SC4/WG1)  is  developing  a  tolerance  model.  Their  July 
1987  working  paper  (Document  3. 1.1.6)  notes  that  as  communication  of  product  defini¬ 
tion  data  comes  to  rely  on  digital  communication  instead  of  engineering  drawings,  the 
importance  of  providing  unambiguous  digital  models  increases. 

Closely  related  to  standards  for  representation,  but  at  a  slightly  more  abstract 
level,  the  concept  of  modeling  provides  a  technique  for  supplying  semantic  meaning  for 
an  item  of  information.  For  example,  one  might  wish  to  capture  not  only  the  design 
object,  but  also  the  designer’s  intent  in  creating  the  object.  Models  of  products  and 
processes  may  be  represented  as  conceptual  schema,  or  they  may  appear  as  mathemati¬ 
cal  expressions.  Accurate  models  promote  understanding  of  the  process  and  simplify 
creation  of  integrated  systems.  Retroactive  creation  of  information  models  is  more  diffi¬ 
cult  than  defining  two-way  exchange  standards  between  systems  that  already  share  the 
same  information  model.  Consequently,  many  researchers  consider  it  to  be  an  essential 
first  step. 

Concurrent  engineering  teams  up  specialists  who  typically  address  designs  using 
their  own  methods,  representations,  and  manual  and  automated  tools.  Given  the  trend 
toward  the  use  of  automation  for  synthesis,  analysis,  and  capture  of  designs,  multifunc¬ 
tion  design  teams  will  require  tools  and  representations  that  work  together  easily. 
Integrating  technologies  are  aimed  at  reducing  the  cost  of  evolvable,  tailorable  tool 
interoperability.  At  the  same  time,  they  have  the  possibility  of  drastically  reducing  the 
DoD  cost  of  receiving  and  maintaining  engineering  data.  Additional  discussion  of  this 
technology  may  be  found  in  [Linn86]. 
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2.3.5. 1  Environment  Framework  Development  and  Standardization 

In  several  meetings  of  groups  concerned  with  the  technological  aspects  of  con¬ 
current  engineering,  some  participants  indicated  that  engineering  environment  frame¬ 
works  are  a  significant  facilitating  technology  for  concurrent  engineering. 

An  engineering  environment  framework  is  a  response  to  the  fact  that  as  design 
complexity  increases,  the  use  of  automated  tools  increases,  but  as  the  use  of  automated 
tools  increases,  complexity  is  added  to  the  engineering  process.  Thus  an  effort  to  manage 
complexity  of  designs  increases  complexity  of  the  engineering  process.  This  point  is  exa¬ 
cerbated  when  designs  are  decomposed  and  addressed  in  highly  interrelated  subtasks  or 
when  specialists  are  required  to  address  various  aspects  of  a  design.  Such  an  approach 
requires  the  following  characteristics  and  requirements: 

•  integrating  and  accessing  information  and  automated  tools  easily; 

•  sharing  multiple  levels  of  design  information  in  a  controlled  fashion; 

•  tracking  design  information; 

•  tracking  design  dependencies  and  changes,  and  propagating  effects;  and 

•  monitoring  the  design  process. 

These  are  characteristics  and  requirements  that  often  increase  as  the  use  of  concurrent 
engineering  increases.  Geographical  dispersion  of  the  team  exacerbates  the  problem, 
because  information  sharing  and  control,  process  control,  and  perhaps  even  tool  integra¬ 
tion  and  access  must  occur  over  electronic  networks. 

To  respond  to  these  requirements,  a  framework  is  needed  for  tool  integration 
based  on  information  sharing.  It  should  offer  a  standard,  extensible  set  of  services  and 
interfaces  to  be  used  by  applications.  It  should  control  and  allocate  data  resources,  pro¬ 
vide  concurrency  controls,  archiving,  and  a  query  capability. 

There  are  five  basic  functions  of  an  engineering  environment  framework  to  sup¬ 
port  concurrent  engineering: 

•  tool  integration — the  ability  to  operate,  efficiently  and  uniformly,  tools  with  dif¬ 
ferent  data  and  hardware  requirements; 

•  data  exchange — the  ability  to  translate  and  to  communicate  data  among  different 
hosts  and  tools  not  only  within  the  the  environment  but  also  between  the  environ¬ 
ment  and  external  systems; 
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•  engineering  and  manufacturing  management  and  control — the  facilities  to  moni¬ 
tor  the  design  and  manufacturing  process  and  to  impose  automatic  and  manual 
controls  on  accessing  and  modifying  data; 

•  information  management — the  facilities  to  describe  and  to  control  globally  avail¬ 
able  environment  data  including  the  creation  and  manipulation  of  data,  the  impo¬ 
sition  of  data  validity  and  constraint  checking,  version  and  configuration  manage¬ 
ment,  concurrent  transaction  control,  and  backup  and  archive  management;  and 

•  environment  administration — the  tools  and  specifications  for  managing  the  data 
dictionary,  tools,  workstations,  user  profiles,  and  control  rules. 

2.3.S.2  Description  of  Engineering  Designs  and  Characteristics 

Some  participants  in  this  study  assert  that  a  necessary  requirement  for  concurrent 
engineering  is  the  ability  to  represent  the  object  being  designed  in  an  accurate,  unambigu¬ 
ous  language.  In  addition,  moving  from  total  reliance  on  design  drawings  to  electronic 
representations  that  can  be  accessed  by  many  team  members  is  an  important  advance  in 
design  technology  that  allows  teams  to  be  more  productive  and  provides  an  opportunity 
for  concurrent,  integrated  execution  of  different  design  tasks.  Other  participants  point  to 
the  existence  of  successful  concurrent  engineering  efforts  of  many  kinds  when  no  such 
language  was  available  and  infer  that  a  common  unambiguous  representation  of  the 
design  object  is  not  necessary. 11  Through  the  CALS  initiatives,  DoD  participates  in  the 
effort  to  develop  such  a  representation  and  foster  its  implementation. 

There  exists  now  a  national  effort  to  develop  such  a  specification.12  There  is  a 
national  voluntary  group,  supported  by  the  CALS  initiative,  whose  goal  is  to  develop  Pro¬ 
duct  Data  Exchange  Specification  (PDES).  An  industrial  cooperative,  PDES  Inc,  has 
formed  to  accelerate  implementation  of  the  technology. 

The  PDES  endeavor  supports  industrial  automation  in  its  broadest  sense.  The 
resulting  standards  would  deal  with  the  entire  range  of  product  data  and  are  intended  to 
represent  the  U.S.  position  internationally  in  the  quest  for  a  single  standard  for  product 
data.  The  term  product  data  denotes  the  totality  of  data  elements  which  completely 
defines  a  product  for  all  applications  over  the  product’s  expected  life  cycle.  The  data 
include  not  only  the  geometry  but  tolerances,  material  properties,  surface  finishes,  and 
other  attributes  and  features  that  completely  define  a  component  part  or  an  assembly  of 
parts. 


11.  The  authors  believe  that  such  a  representation  or  family  of  representations  is  desirable. 

12.  Howard  Bloom  of  the  National  Institute  of  Standards  and  Technology  contributed  to  this  section. 
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PDES  must  provide  the  capability  of  exchanging  data  among  the  multiple  com¬ 
puting  systems  that  will  be  involved  in  the  product  life.  There  is  a  particular  necessity  for 
archived  models  that  will  be  interpreted  at  a  future  date  by  an  unknown  system.  Industry 
has  found  that  the  ability  to  exchange  product  data  among  a  variety  of  different  vendor 
computer  systems  is  critical  to  its  external  relationships  with  contractors  and  customers. 

It  is  important  to  understand  that  the  conceptual  schema  of  the  PDES  model, 
while  built  to  support  application  areas,  is  supposed  to  be  independent  of  both  the  physi¬ 
cal  implementation  and  the  applications  making  use  of  the  information.  The  PDES 
model  is  referred  to  as  the  Integrated  Product  Data  Model  (IPDM). 

2.3.6  Continuous  Improvement 

In  addition  to  taking  major  steps  to  redefine  the  design  process  to  make  it  more 
consistent  with  the  ideas  of  concurrent  engineering,  there  is  a  need  to  recognize  that  most 
processes  are  just  too  complicated  for  managers  or  engineers  to  specify  exactly  a  priori. 
Most  processes  will  either  have  latent  errors  or  will  develop  them  as  the  environment 
changes.  The  concept  of  continuous  improvement  is  intended  to  deal  with  this  situation. 

Under  a  continuous  improvement  plan,  the  workers  who  carry  out  the  process 
together  with  management  are  encouraged  to  understand  it  and  to  think  of  ways  that  it 
might  be  improved.  Most  suggestions  result  in  only  minor  improvements,  but  collectively 
their  impact  can  be  significant. 

A  substantial  effort  is  required  to  prepare  workers  and  managers  to  adopt  a  con¬ 
tinuous  improvement  philosophy.  Among  the  companies  visited,  a  training  expenditure  of 
one-half  percent  of  gross  sales  was  average.  Such  training  is  customary  for  companies 
that  are  starting  a  total  quality  management  effort.  Nash  [Nash89]  provides  a  catalog  of 
training  and  education  sources  for  concurrent  engineering  that  includes  several  sources 
for  training  in  continuous  improvement  methods. 

In  addition  to  continuous  improvement  of  the  development  and  production 
processes,  considerable  effort  has  been  devoted  to  improvement  of  the  product.  Not  nor¬ 
mally  viewed  as  concurrent  engineering,  value  engineering  is  a  program  that  supports  pro¬ 
duct  improvement.  Using  the  same  techniques  that  are  applied  during  concurrent 
engineering,  albeit  often  after  an  item  has  entered  production,  value  engineering  has  been 
credited  [Shaw89  p.  26]  with  over  $2  billion  in  savings  within  the  defense  community. 
Function  analysis  [Snod86]  is  one  of  the  principal  tools  used  in  value  engineering.  The 
functions  of  a  product  are  analyzed,  classified,  assigned  priorities,  and  assigned  a  posi¬ 
tion  either  on  or  supporting  a  critical  path.  Alternatives  can  be  evaluated  in  light  of  their 
ability  to  satisfy  critical  path  functions  at  better  cost.  Within  DOD,  value  engineering 


supports  the  generation,  evaluation,  and  implementation  of  value-engineering  change 
proposals  whose  goal  is  provide  the  customer  with  an  improved  product  while  sharing  the 
benefits  between  the  supplier  and  customer. 

2.3.6. 1  Statistical  Tools 

The  quality  movement  and  the  statistical  community  have  developed  a  collection 
of  methods,  some  simple  and  others  complex,  for  promoting  continuous  process  improve¬ 
ment.  The  “seven  old  tools”  or  Ishikawa’s  [Ishi82]  seven  tools  are  particularly  simple, 
graphic  devices  intended  for  use  by  factory  workers.  They  have  also  proven  useful  for 
professionals  and  are  included  in  AT&T’s  PQMI  [Acke87]  workbook.  Evolutionary 
operation  [Box57]  is  a  technique  for  using  a  process  as  a  continual  source  of  experimen¬ 
tal  data  for  improving  it  in  an  evolutionary  manner.  Box  [Box89]  stresses  the  importance 
of  combining  an  informed  observer  with  a  significant  event  to  learn  from  the  observed 
behavior  of  processes,  including  the  evidence  of  bugs  and  errors. 

2.3.7  Robust  Product  Design 

Since  1981,  the  concept  of  robust  design  has  been  gaining  wider  acceptance 
within  U.S.  industry.  Among  the  workshop  participants  there  was  recognition  that  a 
Japanese  engineer,  Genichi  Taguchi,  can  be  credited  [Phad89]  with  developing  the  key 
elements  of  this  idea. 

2.3.7. 1  Taguchi’s  Contribution 

The  principal  contributions  of  Taguchi  include  reexamination  of  the  role  of 
specifications,  emphasis  on  using  controlled  experiments,  recognition  that  products  are 
built  in  factories  under  environmentally  “noisy”13  conditions,  attention  to  designing  pro¬ 
ducts  to  operate  consistently  under  varying  conditions  (including  aging),  and  re-emphasis 
on  the  need  to  improve  quality  while  lowering  costs.  He  is  credited  with  the  idea  that  pro¬ 
ducing  products  which  are  merely  within  specification  is  not  adequate.  His  formulation  of 
the  concept  of  a  quadratic  “loss  function”  has  sparked  renewed  interest  in  ways  of  reduc¬ 
ing  variability. 

Robust  product  design  starts  with  a  concept  that  quality  can  be  viewed  as  a  loss  to 
society  associated  with  a  product.  The  loss  is  assumed  to  be  a  continuous  function  of  one 
or  more  quality  characteristics  (measurable  characteristics  of  a  product  e.g.  temperature, 
hardness,  dimension,  etc.).  Robust  product  design  seeks  to  find  ideal  target  values  for 
quality  characterists  so  that  the  loss  function  will  be  minimized.  If  such  a  target  value  can 
be  found,  then  not  only  will  the  loss  be  minimized  when  the  that  target  is  achieved,  but 


13.  Sources  of  variation  in  manufacturing,  use,  and  age  that  cannot  be  controlled  with  economically  practical 
methods  are  called  noise  factors. 
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also  the  expected  loss  can  be  calculated  when  that  target  is  not  achieved.  Taguchi  asserts 
that  the  loss  increases  as  the  square  of  the  displacement  from  the  target  value  when  qual¬ 
ity  characteristics  varies  from  the  target  value.  Using  this  concept,  it  no  longer  suffices  to 
produce  items  that  are  “within  specification.”  Taguchi  recommends  use  of  statistically 
designed  experiments  to  help  designers  find  the  parameter  settings  that  will  result  in  a 
product  whose  important  characteristic  is  consistently  close  to  the  ideal  target  despite  the 
presence  of  manufacturing  variations  or  the  effects  of  age.  Moreover,  he  recommends 
that  these  values  be  selected  using  the  least  expensive  materials. 

The  design  steps  involved  are  system  design,  parameter  design,  and  tolerance 
design.  System  design  is  used  to  find  the  best  technology  for  a  product.  Parameter  design 
finds  the  parameter  values  which  optimize  the  product  loss.  It  reduces  the  effects  of  vari¬ 
ability.  Tolerance  design  selects  the  tolerances  that  must  be  used  in  manufacturing  to 
assure  minimum  loss  after  the  product  is  manufactured  and  is  being  used  by  the  customer. 
It  reduces  the  causes  of  variability  in  a  product. 

The  benefits  of  Taguchi’s  approach  have  been  demonstrated  in  automobile 
manufacturing,  electronic  component  production,  computer  operating  systems,  engine 
design,  optimization  of  integrated  circuit  chip  bonding  process,  ultrasonic  weld  process 
optimization,  and  design  of  disc  brake  systems.  The  study  team  heard  reports  of  many 
applications  of  this  technique  and  the  results  have  been  impressive. 

2.3.7.2  Design  of  Experiment 

Design  of  experiment  did  not  originate  with  Taguchi,  but  his  works  have  sparked 
renewed  discussion  and  application  of  this  technique.  Experimental  design  was  invented 
and  developed  in  England  by  Fisher  and  his  colleagues  in  the  1920s.  In  the  1930s  Fisher’s 
ideas  were  also  introduced  into  industry.  At  that  time.  The  Industrial  and  Agricultural 
Section  of  the  Royal  Statistical  Society  was  inaugurated  in  London  and  papers  from 
industry  on  applications  to  manufacture  of  glass,  light  bulbs,  textiles,  etc.,  were  presented 
and  discussed.  This  led  to  new  statistical  methods:  fractional  designs  were  first  used  by 
Tippett  in  1933  to  improve  a  spinning  machine  and  variance  component  analysis  was 
developed  by  Daniels  in  1935  to  reduce  variation  in  textiles. 

During  World  War  II  the  need  for  designs  which  could  screen  large  numbers  of 
factors  led  to  the  introduction  of  fractional  factorial  designs  and  other  orthogonal  arrays 
respectively  by  D.  J.  Finney  (a  student  of  Fisher)  and  by  Plackett  and  Burman,  two  statis¬ 
ticians  working  in  Britain’s  Ministry  of  Defense.  In  1947,  orthogonal  arrays  were  named 
and  further  developed  by  C.  R.  Rao.  Further  notable  work  on  these  designs  were  per¬ 
formed  in  this  country  by  Kempthorne,  Sieden,  Addelman,  Box,  Hunter,  and  others. 


These  designs  have  been  widely  applied  in  industry  and  many  successful  indus¬ 
trial  examples  are  described  in  papers  and  books  dating  from  the  1950s  and,  in  particular, 
by  a  highly  respected  engineer  and  statistician,  Cuthbert  Daniel.  Daniel  also  invented  a 
very  simple  but  important  and  effective  way  of  analyzing  the  designs  using  normal  proba¬ 
bility  plots. 

In  the  early  1950s,  Box,  who  was  then  working  for  the  Imperial  Chemical  Indus¬ 
tries,  developed  new  techniques  called  response  surface  methods  for  the  improvement 
and  optimization  of  industrial  processes  experimentally.  Initially  when  systems  may  be 
far  from  optimum  conditions,  fractional  factorial  designs  and  other  orthogonal  arrays 
were  used  to  estimate  a  path  of  steepest  ascent  to  increased  response.  Once  the  max¬ 
imum  was  approached,  second  degree  approximations  were  used  with  new  types  of 
designs,  introduced  by  Box  and  Hunter  and  others,  to  estimate  the  necessary  coefficients. 
Further  analysis  was  used  to  study  ridge  systems  which  might  allow  simultaneous  maximi¬ 
zation  of  more  than  one  response  (e.g.,  maximum  yield  with  minimum  impurity). 
Response  surface  methods  are  routinely  used  by  such  companies  as  3M,  DuPont,  General 
Electric,  Allied  Signal,  and  Dow  Chemical  to  improve  and  optimize  their  processes,  and 
many  successful  industrial  applications  have  been  described  in  numerous  papers  and 
books  published  over  the  last  30  years. 14 

In  some  industries,  particularly  the  chemical  industry,  there  is  a  tradition  extend¬ 
ing  over  several  decades  concerning  the  use  of  statistical  methods  including  design  of 
experiment.  In  other  industries,  statistical  methods  have  only  recently  been 
rediscovered.  There  is  a  possible  correlation  between  use  of  different  design-of-experi- 
ment  methods  and  the  type  of  industry  using  a  particular  method. 

Taguchi  introduced  some  variations  to  the  statistical  techniques  used  during  the 
later  phases  of  robust  design.  Evaluation  of  the  benefits  and  limitations  of  these  particu¬ 
lar  variations  is  a  subject  of  continuing  research  [NIST89J. 

Among  the  companies  contacted,  the  use  of  robust  design  has  been  credited  with 
some  of  the  most  spectacular  cost  savings,  ranging  up  to  80  percent  in  some  cases.  In 
other  cases  [Winn88  p.  59],  robust  design  techniques  are  credited  with  preventing  the 
early  termination  of  entire  product  lines.  Seven  companies  reported  success  with  robust 
design  techniques. 


14.  We  are  indebted  to  Dr.  George  Box,  Center  for  Quality  and  Productivity  Improvement,  University  of 
Wisconsin-Mad ison,  for  contributing  the  information  in  this  section. 
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2.3.7.3  Competitive  Benchmarks 

Competitive  benchmarking  is  not,  strictly  speaking,  a  concurrent  engineering 
technique.  Competitive  benchmarking  is  a  technique  applied  by  several  companies  to 
evaluate  the  quality  of  their  product  and  process  designs.  Typically,  competitors’  pro¬ 
ducts  are  purchased,  evaluated  for  performance,  and  disassembled  to  evaluate  the  effec¬ 
tiveness  of  the  design  techniques  and  production  process  used  to  make  the  item.  The 
company  performing  the  analysis  gains  knowledge  about  the  state  of  practice  in  their 
industry  and  they  establish  various  benchmarks  that  can  be  used  to  evaluate  the  quality  of 
their  own  products. 

There  may  be  different  variations  of  the  process,  but  it  is  widely  practiced.  Three 
companies  mentioned  it  as  an  element  of  their  normal  product  development.  If  a  com¬ 
pany  has  a  rule  that  new  designs  must  be  the  best  in  the  class  or  world  class,  then  com¬ 
petitive  benchmarking  is  one  method  for  establishing  quantitative  measures  for  achieving 
that  goal. 

2.3.8  Breakthroughs 

Whether  or  not  a  company  chooses  to  apply  concurrent  engineering,  they  will 
always  be  vulnerable  to  finding  their  products  obsolete  if  a  competitor  achieves  a  break¬ 
through  in  product  or  process  technology.  Companies  have  traditionally  relied  on 
research  and  development,  internal  and  academic,  for  new  product  and  process  ideas. 
Some  directed  the  research  into  areas  that  were  thought  to  be  most  important  and  others 
supported  research  in  areas  that  were  broadly  defined. 

Juran  [Jura88  5.20,  22.12]  discusses  the  relationship  of  a  quality  improvement 
program  and  the  ability  to  set  objectives  for  breakthroughs.  He  also  provides  a  sequence 
of  events  that  are  associated  with  breakthroughs. 

One  company  visited  during  this  study  has  adopted  a  formal  planning  method  to 
identify  critical  areas  and  focus  attention  on  those  areas  so  as  to  achieve  breakthroughs. 
They  do  not  limit  breakthroughs  to  the  fruits  of  research,  but  also  target  marketing,  finan¬ 
cial,  and  management  functions.  This  company  adopted  a  planning  process  called 
Hoshin  Kanri,  and  they  practice  it  extensively. 

Other  companies  might  be  performing  a  similar  process  under  the  label  of  stra¬ 
tegic  planning.  However,  the  adoption  of  a  well-defined  procedure  for  such  planning  at 
all  levels  of  a  corporation  seems  likely  to  produce  additional  benefits.  Only  two  com¬ 
panies  described  formal  strategic  planning  processes. 
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2.4  FRAMEWORK 


The  authors  believe  that  the  problem-oriented  view  of  methods  and  tools  provides 
a  useful  framework  for  considering  when  to  use  them.  The  preceding  discussion,  how¬ 
ever,  is  only  intended  to  be  an  introduction.  For  sources  of  further  discussion  of  the  indi¬ 
vidual  tools,  the  reader  is  referred  to  An  Annotated  Reading  List  for  Concurrent 
Engineering  [Pen89]. 

Table  1  provides  a  summary  of  the  problem-oriented  framework  for  methods  and 

tools. 
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Table  1.  Framework  of  Methods  and  Tools 


USE 

Determine  Customer  Wants 


Establish  Process  Control 

Define  the  Process 


METHOD  OR  TOOL  REMARKS 


Multifunction  Teams 

Customer  Surveys 

Send  Engineers  to  the  Customer 

Supportability  Awareness  Training 

QFD 

In-House  Techniques 


PQMI 
Flow  Charts 

Brain  Storming 
Computer-Aided  Modeling 

Operational  Definitions 
DoD  4245.7 

NAVSO  P-6071 

R&M2000 


At  least  manufacturing  and  design, 
(manufacturing  is  design’s  customer)  usu¬ 
ally  more,  often  8-12  people  who  work  on 
a  component 

Traditional  marketing  approach 


Without  genuine  support  this  may  not  be 
taken  seriously 

QFD  charts  are  only  the  final  part  of  this 
effort,  the  thought  process  and  interaction 
of  different  groups  are  more  significant. 
The  charts  only  record  the  result. 

Sending  engineers  to  the  factory,  factory 
workers  to  the  distributors,  giving  pro¬ 
ducts  to  employees  for  evaluation.  Place 
people  in  a  new  role. 


An  AT&T  approach  described  in  [Acke87] 

Widely  used  to  describe  tasks,  but  creative 
efforts  are  difficult  to  capture. 


Particularly  useful  when  different  func¬ 
tional  groups  can  access  a  common  com¬ 
puter-based  product  and  process  descrip¬ 
tion  even  when  different  evaluation  or  syn¬ 
thesis  tools  are  used. 


“Best  practices,”  they  should  support  the 
concurrent  engineering  concept  if  they  are 
not  misinterpreted  as  mandating  a  strictly 
sequential  development. 


An  Air  Force  program  that  clearly  stresses 
the  importance  of  reliability  and  main- 
tainablity  for  new  weapons  systems. 


Supports  many  QFD  efforts 


See  Deming 


See  best  practices 


e.g.,  USAF  Blue-two 
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USE 


METHOD  OR  TOOL 


REMARKS 


Measure  Process  Characteristics  None 


Control  the  Process 


SPC 

Pareto  Diagrams 
Cause  and  Effect  Diagrams 

PERT  Diagrams 

Reactive,  Preventive,  Progressive, 
and  Dynamic  Control 

CUSUM 

EWMA 

On-Line  Process  Control 


Statistical  process  control,  well-known  in 
manufacturing,  but  also  applicable  in  ser¬ 
vice  tasks  including  engineering  and 
design 

A  simple  histogram  to  show  what  prob¬ 
lems  should  be  attacked  first. 

Sometimes  called  the  fishbone  or  Ishikawa 
diagrams — a  kind  of  tree  with  effect  at  the 
root  and  causes  as  the  branches  and 
leaves. 

A  directed  graph  showing  the  relationship 
of  tasks  in  a  schedule.  Tasks  are  usually 
the  nodes  and  arcs  show  precedence  rela¬ 
tions. 

Hayes  et.al.,  describe  increasing  levels  of 
control  that  equate  to  increased  levels  of 
quality  and  greater  advantage  for  the  prac¬ 
ticing  company.  Dynamic  control  pro¬ 
vides  the  greatest  competitive  advantage. 

A  technique,  related  to  SPC,  but  espe¬ 
cially  good  for  detecting  gradual  shifts  in 
the  mean. 

A  technique  for  predicting  trends  and 
evaluating  the  accuracy  of  the  prediction. 
Possible  use  with  feed-forward. 

[Tagu86  p  83]  describes  three  forms:  diag¬ 
nosis  and  adjustment,  prediction  and 
correction,  and  measurement  and  action. 


Improve  the  Process 

Multifunction  Teams 
Design  Evaluation  Tools 
CATV 

Logic  Analyzers 
Fault  Simulators 
Thermal  Analysis  Tools 


Discussed  above. 

Computer-based  and  checklists 

Timing  simulations  for  circuit  designs 

For  electronic  circuit  designs 

Used  for  circuit  design  verification 

Predict  hot  spots  that  usually  indicate 
points  of  low  reliability 
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USE 


Continuoui  Improvement 


Design  Robust  Products 


METHOD  OR  TOOL  REMARKS 


Design  for  Assembly 
Fault  Tree  Analysis 


Failure  Mode  Effects  Analysis 


LSSD 


BILBO 


Standardization 


Environment  Frameworks 


Description  Languages 


See  Boothroyd  and  Dewhurst,  23 

Both  a  traditional  aerospace  validation 
technique  and  one  of  the  so-called  seven 
new  or  management  tools  of  Japanese 
management. 

Used  to  identify  critical  failure  modes, 
traditionally  used  to  help  design  more 
robust  or  safer  products. 

A  set  of  design  rules  introduced  by  IBM, 
when  followed  the  designs  have  certain 
nice  features  for  testing. 

A  circuit  design  technique  to  simplify  test¬ 
ing. 

Use  of  standard  or  approved  parts  speeds 
design  and  avoids  surprises  for  purchasing 
and  manufacturing. 

A  concept  that  promotes  interoperability 
of  design  tools,  databases,  evaluation 
tools,  and  other  computer  software  and 
hardware  needed  to  support  the  entire 
enterprise 

Computer  descriptions  of  products  and 
processes. 


Value  Engineering 


Ishikawa’s  Seven  Tools 


Evolutionary  Operation 


Similar  concept  to  concurrent  engineer¬ 
ing,  except  that  is  is  often  applied  only 
after  the  product  has  been  developed  and 
is  in  production. 

Simple  devices  to  help  factory  workers 
monitor  and  improve  quality.  They  can  be 
used  in  service  and  design  sectors. 

Concept  of  measuring  the  effects  of  very 
small,  controlled  variation  in  process  con¬ 
trols  to  see  how  process  can  evolve  to  pro¬ 
duce  better  quality  products. 


Taguchi  Concepts  Importance  of  reducing  variation,  within 

specification  is  not  enough,  during  design 
anticipate  variation  or  noise  in  manufac¬ 
turing  and  operation  of  the  product,  use 
experiments  to  select  optimum  parame¬ 
ters. 
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USE 


Other  Improvements 


METHOD  OR  TOOL  REMARKS 


Design  of  Experiment  Technique  for  efficiently  evaluating  effects 

of  changing  multiple  parameters  simul¬ 
taneously. 

Competitive  Benchmarks  Evaluate  the  best  features  of  competitors 

products,  including  an  estimate  of  the  cost 
to  manufacture  and  operate  the  product 
so  that  targets  for  new  products  can  be 
established. 


Breakthroughs 


Hoshin  Kanri 


Discoveries  in  products  or  processes  that 
give  a  company  a  significant  market  advan¬ 
tage. 

A  technique  for  focusing  energy  on  areas 
where  breakthroughs  are  needed. 
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3.  EVALUATION  OF  METHODS 


Several  people  have  asked  for  a  ranking  of  the  various  tools  or  methods  that  have 
been  associated  with  concurrent  engineering  or  with  TQM.  Sometimes  the  person  making 
the  request  wants  to  know  where  to  start  in  their  quality  or  productivity  improvement 
effort.  Other  people  are  looking  for  a  method  of  grading  companies  as  to  which  ones  are 
“better”  at  concurrent  engineering. 

During  the  original  workshops,  an  attempt  was  made  to  develop  information  that 
would  support  such  a  ranking.  For  the  reasons  outlined  in  this  section,  the  attempt  was 
not  successful  and  neither  were  our  efforts  during  this  study.  Following  the  suggestion  of 
the  NIST  workshop,  the  authors  associated  the  methods  with  the  problems  being  solved 
and  also  reported  such  associations  of  methods  with  classes  of  benefits  as  could  be  sup¬ 
ported  by  the  available  evidence. 

3.1  THE  PROBLEM  OF  RANKING  METHODS 

Although  Winner  [Winn88  p.  129]  developed  a  framework  for  concurrent 
engineering  and  the  preceding  section  presented  a  problem-oriented  framework  for 
methods  and  tools,  the  relative  novelty  of  studing  concurrent  engineering  has  not  pro¬ 
vided  an  accumulation  of  data  necessary  for  complete  analysis  in  this  field.  For  example, 
based  on  the  data  available,  a  final  ranking  of  tools  or  methods  cannot  be  completed  now 
for  two  reasons.  First,  the  list  of  potential  methods  is  not  stable  and,  second,  there  is  no 
generally  accepted  criterion  for  measuring  the  benefits  associated  with  individual  tech¬ 
niques. 

3.1.1  Changing  Lists 

During  this  study,  the  authors  considered  four  different  lists  of  methods  and 
finally  concluded  that  none  of  them  could  be  considered  as  final.  The  diversity  is  illus¬ 
trated  below.  The  IDA  report  [Winn88  p.  112,114]  describes  thirteen  methods  and  tech¬ 
niques  associated  with  concurrent  engineering.  It  then  cites  a  list  of  26  methods  and  tech¬ 
niques  generated  during  one  workshop  and  finally  mentions  a  list  of  23  methods  that  were 
reported  at  a  1987  Japanese  conference.  Figure  3  shows  the  list  of  methods  that  were 
identified  during  the  1988  IDA  workshops  as  having  some  association  with  concurrent 
engineering. 


1.  Quality  Function  Deployment 

2.  Threat  Analysis 

3.  Technology  research  and  transfer 

4.  System  Design,  Parameter  Design,  and  Tolerance  Design  (Taguchi  Method) 

5.  Testing  Methods 

6.  Problem  History  Feedback 

7.  Design  for  Simplicity 

8.  Design  for  Assembly 

9.  Rule-Based  Design 

10.  Simulation  (Soft  Mock-up) 

11.  Common  Parts  Database  with  Reliability,  Maintainability,  and  Producibility  Information 

12.  Pugh  Concept  Development 

13.  Fault  Tree  Analysis  (FTA) 

14.  Failure  Mode  Effects  Analysis  (FMEA) 

15.  On-line  Quality  Control 

16.  Design  of  Experiments 

17.  Response  Surface  Methods 

18.  Evolutionary  Operations  (EVOPS) 

19.  Exploratory  Data  Analysis 

20.  Statistical  Graphics 

21.  Group  Technology 

22.  Value  Engineering 

23.  Measurement  Methods 

24.  Operational  Definitions 

25.  Ishikawa’s  Seven  Tools  (Graphs,  Histograms,  Cause-and-Effect  Diagrams,  Check  Sheets, 
Pareto  Diagrams,  Control  Charts,  Scatter  Diagrams) 

26.  Foolproofing 


Figure  3.  Tools  and  Techniques  to  Support  Concurrent  Engineering 
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After  attempts  to  develop  a  consistent  ranking  of  the  importance  of  these  tools, 
participants  determined  that  such  a  ranking  would  be  misleading.  Each  of  these  tech¬ 
niques  serves  a  different  purpose;  each  is  a  different  tool  to  be  used  during  product 
development.  Saying  that  one  tool  is  more  important  than  another  makes  no  more  sense 
than  saying  that  a  saw  is  more  important  than  a  hammer  for  a  carpenter.  Just  as  a  good 
carpenter  uses  a  variety  of  tools,  so  an  engineering  team  uses  a  variety  of  methods  and 
tools.  In  many  domains,  familiarity  with  some  minimal  set  of  tools  is  seen  as  entry-level 
qualification  and  experts  are  the  individuals  who  understand  a  wide  variety  of  methods 
and  can  apply  the  correct  approach  to  the  problem  at  hand. 

In  Section  2  of  this  paper,  forty-four  different  methods  or  tools  are  mentioned. 
EDA  is  not  alone  in  noting  fluctuation  in  the  lists  of  methods  and  tools.  A  speaker  at  a 
company  workshop  who  has  been  a  frequent  visitor  to  Japan  reports  a  similar  phenomena 
in  that  country — on  each  visit  he  saw  a  different  list  of  tools  and  methods. 

The  authors’  experience  derived  from  visiting  different  companies  or  participat¬ 
ing  in  different  workshops  is  that  no  list  of  methods  used  in  concurrent  engineering  or  in 
TQM  should  ever  be  considered  complete.  Therefore,  the  authors  believe  that  a  com¬ 
plete  ranking  of  such  tools  or  methods  is  neither  feasible  nor  desirable. 

3.1.2  Confounded  Causes  and  Effects 

The  difficulty  of  developing  a  complete  list  notwithstanding,  the  problem  of 
assigning  specific  benefits  to  the  use  of  individual  methods  based  on  available  data 
remains  intractable.  During  the  concurrent  engineering  task,  IDA  collected  data  from  a 
number  of  companies.  Because  the  data  were  not  the  result  of  preplanned  experiments, 
they  could  not  be  used  to  support  strong  conclusions  about  correlations  of  tools  with  bene¬ 
fits.  The  data  do  not  support  a  statistical  regression  analysis  because  potential  variables 
were  not  originally  controlled  and  benefits  were  not  measured  using  consistent  metrics. 
Nevertheless,  where  benefits  could  be  assigned  the  role  of  response  variables,  anecdotal 
association  of  benefits  with  different  methods  was  developed.  The  benefits  were  classi¬ 
fied  according  to  whether  they  were  quality  improvements,  cost  reductions,  or  shortened 
schedules.  The  next  section  contains  associations  of  different  methods  with  benefits  of 
each  type. 

The  difficulty  of  providing  cause-effect  relationships  concerning  concurrent 
engineering  (or  TQM)  is  not  limited  to  the  IDA  study.  In  general,  the  companies  practic¬ 
ing  either  approach  have  not  developed  a  rigorous  mapping  of  benefits  to  the  use  of  indi¬ 
vidual  initiatives.  In  fact,  when  questioned  about  this  idea,  there  was  some  indication  that 
such  a  mapping  was  intentionally  avoided.  One  company  (that  had  been  contacted  dur¬ 
ing  the  first  phase  of  the  study  and  was  later  revisited)  identified  more  than  80  internal 
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improvement  actions,  but  said  they  were  unable  to  show  how  much  each  of  the  actions 
contributed  to  their  overall  improvement.  Their  approach  did  not  include  a  program  for 
corporate-wide  standardization  on  the  individual  elements  of  their  improvement  initia¬ 
tives.  They  said  that  individual  divisions  were  free  to  interpret  for  themselves  how  to 
implement  the  various  ideas. 

During  this  study,  collective  attempts  to  develop  cause-effect  relationships  for 
tools  and  methods  were  also  unsuccessful.  In  September  1988,  participants  at  an  EDA 
workshop  attempted  to  apply  QFD  to  the  problem  of  ranking  the  various  methods  and 
tools  of  concurrent  engineering.  The  effort  failed  because  the  members  could  not  come  to 
agreement  on  how  the  different  problems  which  were  being  addressed  should  be  ordered. 
In  fact,  when  a  company  is  faced  with  one  problem,  that  particular  problem  becomes  the 
most  important  one  at  that  moment.  After  realizing  that  agreement  on  an  ordering  was 
not  achievable,  the  members  agreed  to  disagree  on  how  the  methods  and  tools  should  be 
ranked. 

If  experiments  were  to  be  planned  with  a  goal  of  establishing  correlations  among 
different  methods  and  specific  benefits,  then  the  experimental  effort  would  be  expensive 
and  time  consuming.  Suppose  one  were  interested  in  evaluating  the  primary  effects  and 
just  the  two-factor  interactions  for  11  methods  where  a  given  method  was  either  used  or 
not  used.  Using  typical  statistical  techniques[Box78  p.407]  one  might  chose  a  resolution 
V  fractional  factorial  design  requiring  128  separate  experiments.  To  be  realistic,  each 
experiment  would  involve  the  complete  development  of  a  product.  If  other  factors  were 
to  remain  under  reasonable  control,  e.g.,  technology,  qualifications  of  the  workers,  etc., 
then  the  experiments  would  be  performed  within  the  same  company  using  the  same  pro¬ 
duct  line.  After  the  experiments  were  completed,  one  would  not  be  certain  that  the  con¬ 
clusions  would  be  valid  in  other  situations.  The  delay  and  expense  of  producing  such 
results  does  not  appear  warranted  in  light  of  a  considerable  body  of  anecdotal  evidence 
suggesting  that  certain  classes  of  tools  have  been  applied  with  success  in  solving  certain 
types  of  problems.  In  the  opinion  of  the  authors  and  industry  participants,  the  decision  of 
which  tools  to  apply  is,  best  left  to  the  people  responsible  for  identifying  and  solving  the 
particular  problems. 

Similar  opinions  were  developed  at  a  recent  workshop  [NIST89]  on  quality  and 
productivity.  Its  final  report  recommended  against  premature  comparisons  of  the  benefits 
of  different  tools  or  methods.  Instead,  they  recommended  [NIST89]  concentrating  on 
identifying  which  problems  should  be  solved  first  and  looking  for  the  tool  most  likely  to  be 
of  use  in  solving  that  problem. 


3.2  ASSOCIATION  OF  METHODS  WITH  IMPROVEMENTS 


In  this  section  we  present  such  associations  of  general  classes  of  methods  and 
benefits  (quality,  cost,  and  schedule  improvements)  as  could  be  established  with  the  avail¬ 
able  data. 

3.2.1  Quality  Improvements 

A  review  of  the  original  case  studies  together  with  subsequent  visits  to  several 
companies  provided  a  count  of  the  number  of  times  each  of  the  factors  listed  above  was 
mentioned  as  contributing  to  improved  quality.  These  frequencies  are  presented  in  Figure 
4.  The  categories  of  engineering  process  initiatives,  technology  support,  and  formal 
methods  were  introduced  in  [Winn88]  and  represent  a  very  rough  grouping  of  methods 
and  tools  according  to  whether  they  were  developed  by  management  (including  manage¬ 
ment  consultants),  by  computer  or  technology  support  groups  (including  CAD  vendors), 
or  by  the  quality  department  (including  statistician  consultants). 

Figure  4  shows  that  the  most  frequently  cited  tools  were  from  the  first  two  classes. 
Although  there  is  a  temptation  to  associate  effectiveness  of  methods  with  number  of  times 
their  use  is  mentioned,  there  is  insufficient  data  to  support  that  conclusion.  One 
aerospace  company  said  that  they  would  not  be  able  to  develop  such  a  correlation 
because  they  could  not  separate  the  interactions  among  different  factors. 

One  electronics  company  provided  a  detailed  breakout  showing  correlation 
among  quality  improvement  initiatives  and  benefits  achieved.  They  completed  19  docu¬ 
mented  quality  improvement  projects  during  a  two-year  period.  The  distribution  of  bene¬ 
fits  was  approximately  even  among  quality,  cost,  and  schedule  improvements.  In  addi¬ 
tion  to  cost  improvements,  they  noted  six  categories15  of  other  benefits,  three  of  which  are 
related  to  quality  (improve  customer  satisfaction,  improve  conformance  to  customer 
requirements,  and  reduce  customer  confusion). 

Eight  of  the  19  projects  involved  development  and  use  of  better  computer  tools. 
Of  these,  all  provided  better  customer  satisfaction,  two  improved  conformance  to  custo¬ 
mer  requirements,  and  two  helped  to  reduce  customer  confusion. 

Figure  5  shows  that,  within  this  company,  the  computer-based  quality  improve¬ 
ment  projects  (QIP)  were  customer  focused. 


15.  The  six  categories  are:  improve  customer  satisfaction,  conform  to  customer  requirements,  decrease 
critical  path  interval,  reduce  customer  confustion,  increase  productivity,  and  decrease  off  critical  path 
interval. 
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Figure  4.  Use  of  Various  Classes  of  Methods 
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Figure  5 


Number  of  benefits  reported 
in  each  of  three  areas  due  to 
customer-focused  computer 
projects. 
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Figure  5.  Results  of  Computer-Based  Initiatives 
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Figure  6  shows  that  of  the  eleven  projects  involving  management  initiatives,  eight 
reduced  customer  confusion,  seven  provided  improved  customer  satisfaction,  and  four 
improved  conformance  to  customer  requirements.  For  this  organization,  customer  focus 
had  become  important  among  both  the  technical  staff  and  management. 

These  numbers,  the  result  of  one  company’s  quality  improvement  program,  show 
that  changes  designed  as  part  of  a  quality  improvement  program  can  produce  benefits  in 
cost,  schedule,  and  quality.  They  also  show  that  quality  improvement  uses  tools  from 
each  of  the  three  categories  identified  in  [Winn88]. 

3.2.2  Cost  Improvements 

During  the  original  IDA  study,  companies  reported  cost  benefits  from  using  con¬ 
current  engineering.  These  benefits  were  often  expressed  in  terms  of  cost  avoidance  and 
were  often  higher  than  30  percent.  The  savings  were  usually  not  attributed  to  particular 
tools,  except  in  the  case  of  some  statistical  tools. 

The  companies  practicing  “robust  design  methods”  were  an  exception.  They  fre¬ 
quently  cited  specific  cost  savings  and  did  so  in  terms  of  actual  dollar  savings.  Sometimes 
savings  were  calculated  using  a  theoretical  “loss  function”  improvement,  but  often  they 
were  expressed  in  absolute  terms. 

Because  of  the  disparaties  among  methods  for  calculating  cost  improvements, 
assessing  the  incremental  contribution  of  such  methods  to  an  overall  cost  was  not  possible 
with  the  available  data. 

The  electronics  company  mentioned  in  the  preceding  section  provided  data  about 
the  cost  of  the  various  initiatives  as  well  as  the  cost  benefits  associated  with  each  QIP. 
Their  cost  benefits  however  were  not  calculated  according  to  a  consistent  accounting  rule, 
but  were  engineering  estimates  of  the  cost  savings.  Nevertheless,  the  ratio  of  benefits  to 
cost  of  the  initiative  was  approximately  constant  at  10:1  for  QIPs  from  each  of  Winner’s 
three  classes  of  tools. 

Two  “rules  of  thumb”  about  cost  improvements  associated  with  concurrent 
enginering  or  TQM  methods  were  offered  during  the  study.  One  company  claimed  a  $4 
improvement  in  profit  for  every  $1  improvement  in  quality  indicators.  Another  reported 
an  average  $10  benefit  for  every  $1  spent  for  quality  improvements. 

3.2.3  Schedule  Improvements 

No  special  methods  were  identified  for  reducing  schedules,  but  schedule  reduc¬ 
tion  was  reported  by  almost  every  company  contacted.  There  were  thirty-nine  benefits 
reported  to  be  associated  with  the  use  of  multifunction  teams.  Thirteen  involved 
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Figure  6.  Results  of  Process  Improvement  Initiatives 
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schedule  improvement  and  the  average  benefit  was  a  fifty-seven  percent  improvement. 
However,  for  the  same  use  of  multifunction  teams,  fourteen  benefits  were  cost  reductions 
and  twelve  were  quality  improvements.  The  benefits  of  multifunction  teams,  therefore, 
are  equally  felt  in  cost,  schedule,  and  quality  improvements. 

Other  factors  resulting  in  reduced  time-to-market  include  the  decision  to  reduce 
the  number  of  prototype  models  to  be  produced,  the  decision  to  use  parts  and  com¬ 
ponents  from  a  standard  database,  the  early  participation  of  suppliers  during  concept 
definition,  and  better  capture  of  the  customer’s  requirements  (e.g.,  through  the  use  of 
QFD). 

Automation,  including  selective  use  of  computer-aided  design  tools,  clearly  con¬ 
tributes  to  decreased  times  for  certain  operations.  Although  not  strictly  a  concurrent 
engineering  element,  it  was  reported  by  the  companies  visited  as  part  of  their  process 
improvement  efforts.  These  approaches  are  basically  examples  of  using  automation  to 
speed-up  an  existing  process,  but  schedule  improvement  was  the  most  frequently  cited 
benefit  for  the  use  of  computer-aided  engineering  design  and  analysis  tools. 

Schedule  improvements  cited  in  [Winn88]  include  reports  of  orders  of  magnitude 
improvements  for  some  particular  process  step  (usually  the  result  of  using  a  better  CAD 
tool)  to  more  modest  improvements  in  time-to-market  for  a  full  product.  The  later 
category  ranged  from  40  to  60  percent  improvement  compared  to  previous  products  of 
similar  complexity  developed  before  concurrent  engineering  was  adopted.  The  reports  of 
large  improvements  associated  with  CAD  typically  refer  to  reduction  in  the  time  to  per¬ 
form  some  discrete  task  within  the  development  process  and  are  not  necessarily  represen¬ 
tative  of  overall  improvement  of  the  entire  process. 

Of  the  formalized  methods  that  were  mentioned  by  companies  during  this  study, 
design  for  manufacture/design  for  assembly  and  design  of  experiment  were  mentioned 
most  often  as  producing  schedule  improvements.  In  the  judgement  of  the  authors,  the 
most  important  role  for  formalized  methods  is  the  improvement  of  quality.  When  quality, 
including  the  repeatability  of  the  design  processes,  is  improved,  then  both  breakthrough 
and  continuous  improvements  in  the  schedule  are  possible.  Without  improved  quality, 
there  can  be  no  significant  or  sustained  schedule  improvement. 
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4.  RECOMMENDATIONS 


The  various  classes  of  activities  that  have  been  identified  with  concurrent 
engineering  have  been  shown  to  produce  multiple  benefits.  The  association  of  methods 
with  benefits  is  complex  because  single  benefits  result  from  the  application  of  several 
methods  and  single  methods  result  in  multiple  benefits.  The  importance,  therefore,  of 
any  particular  tool,  or  method,  depends  almost  entirely  on  the  situation  existing  when  it  is 
applied — what  problem  is  being  solved.  Accordingly  any  attempt,  at  this  time,  to  rank 
the  tools  in  order  of  importance  would  necessarily  be  arbitrary  and  misleading.  The 
Department  of  Defense  would  not  benefit  from  such  a  list  because  it  would  seem  to  com¬ 
pare  like  items  while  not  doing  so. 

It  is  tempting  to  look  for  some  quantitative  expression  to  model  the  concurrent 
engineering  approach,  but  we  have  found  no  evidence  to  indicate  that  the  search  would 
be  productive.  The  benefits  to  be  derived  from  adopting  concurrent  engineering  cannot 
as  yet  be  expressed  accurately  in  an  equation  where  the  methods  and  tools  are  the 
independent  variables. 

Although  a  strict  ordering  might  not  be  useful  and  a  simplistic  cause-effect  chart 
could  be  misleading,  the  subject  of  concurrent  engineering  has  just  recently  gained  wide 
attention.  As  with  other  subjects  of  recent  attention,  the  initial  examinations  of  the  area 
may  seem  to  produce  data  that  seem  to  defy  classification.  Because  the  data  are  not 
clearly  defined  and  relationships  are  not  the  subject  of  carefully  drawn  theories  or  even 
testable  hypotheses,  some  observers  might  dismiss  the  concept  of  concurrent  engineering 
entirely.  The  authors  believe  that  such  a  dismissal  would  be  a  mistake.  We  are  convinced 
that  the  companies  we  visited  have  found  significantly  better  ways  to  develop  their  pro¬ 
ducts. 


More  study  is  needed  before  comprehensive  theorems  or  even  reasonable  axioms 
about  concurrent  engineering  can  be  offered.  Table  1  provided  one  framework,  albeit 
only  partially  completed,  for  such  future  study.  Winner  [Winn88  p.129]  offers  another. 
Neither  one  suggests  either  a  strict  cause-effect  relationship  or  a  comparison  that  some 
tools  are  better  than  others.  This  observation  leads  to  the  first  recommendation. 

1.  Recommendation:  When  continuing  to  conduct  research  in  concurrent  engineering 
or  the  associated  tools  and  methods,  choose  a  framework  that  relates  them  to  the 


problems  to  be  solved.  Instead  of  trying  to  find  a  best  tool,  try  to  understand  how 
the  different  tools  have  worked,  where  they  haven’t  worked,  and  how  they  can  be 
improved.  Understand  the  problems  that  have  been  encountered  and  suggest  areas 
for  research  to  develop  new  tools  to  solve  them  or  to  improve  the  tools  that  are 
already  available. 

The  authors  believe  that  in  studying  the  tools,  it  will  be  useful  to  involve 
researchers  from  several  disciplines.  Learning  why  certain  tools  such  as  SPC  or 
design  of  experiment  have  not  been  used  might  be  more  instructive  than  developing 
a  quantitative  model  of  how  these  tools  work.  For  over  50  years  people  have  known 
that  the  tools  work,  yet  their  use  has  been  cyclic — widely  used  during  the  1940s, 
infrequently  used  during  the  1960s  and  1970s,  and  being  rediscovered  in  the  1980s. 

Participants  in  this  study  reported  that  workshops  were  beneficial  both  for  sharing 
information  and  for  generating  a  body  of  case  studies.  Hearing  participants  describe  how 
they  solved  various  classes  of  problems  using  either  new  or  traditional  tools  helped 
several  companies  develop  their  own  concurrent  engineering  programs.  The  open  discus¬ 
sion  of  how  other  organizations  identified  the  problems  is  at  least  as  important  as  learning 
how  the  problem  was  solved.  Since  the  1988  workshops,  the  authors  have  heard  from 
several  of  the  participants  who  reported  that  their  companies  have  moved  to  adopt  solu¬ 
tions  that  were  presented  during  the  workshops.  Additionally,  people  said  that  contacts 
established  during  the  workshops  provided  a  network  that  could  be  used  to  exchange 
ideas  about  common  problems.  There  is  considerable  support  for  continued  workshops 
where  further  sharing  of  problems  and  solutions  can  take  place. 

Further,  if  a  sufficient  body  of  case  studies  is  available,  then  qualitative  analytic 
approaches  might  prove  useful  in  promoting  better  product  development  techniques. 

2.  Recommendation:  OSD,  in  conjunction  with  professional  associations,  should 
establish  a  regular  series  of  workshops  where  participants  can  describe  how  they 
identified  and  solved  problems  to  improve  the  quality  of  their  products  or  produc¬ 
tivity  of  their  companies.  These  workshops  could  be  jointly  sponsored  by  TQM, 
value  engineering,  concurrent  engineering,  or  other  effort  with  goals  of  improving 
the  weapons  system  acquisition  process. 

The  Department  of  Defense  faces  a  dilemma  regarding  concurrent  engineering. 
On  the  one  hand,  it  wants  to  encourage  its  suppliers  to  use  the  most  efficient  methods  so 
as  to  provide  products  of  the  highest  quality,  according  to  realistic  schedules,  and  within 
reasonable  budgets.  On  the  other  hand,  it  does  not  want  to  impose  any  particular  process 
on  its  suppliers  as  such  efforts  have  been  shown  to  be  counter  productive. 
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Some  companies  faced  with  a  similar  problem  have  achieved  their  desired  goals 
by  requiring  their  suppliers  to  apply  for  the  Baldrige  Prize  or  other  quality  award.  The 
suppliers  were  given  help  initially,  but  they  were  responsible  for  developing  their  own  pro¬ 
grams.  Several  participants  in  this  study  suggested  that  OSD  take  a  similar  approach. 
The  attractive  aspects  of  the  suggestion  are  that  companies  efforts  to  improve  their  qua' 
ity  would  be  evaluated  by  an  independent  agency  (not  associated  with  DoD)  and,  impli¬ 
citly,  that  companies  demonstrating  superior  quality  would  be  rewarded  accordingly.  The 
dangers  are  that  if  applied  by  DoD  it  might  generate  another  administrative  bureaucracy 
and  that  unscrupulous  companies  would  merely  go  through  the  motions  of  improving  qual¬ 
ity  such  as  applying  for  an  award  merely  to  satisfy  the  DoD  requirement. 

3  Recommendation:  If  an  effort  is  needed  to  improve  the  quality  and  productivity  of 
the  supplier  base  for  DoD,  and  if  DoD  seeks  to  establish  continuing  associations 
with  those  companies  that  measure  up  to  an  externally  specified  quality  standard, 
then  OSD  should  evaluate  the  effectiveness  of  commercial  organizations  that  have 
encouraged  their  suppliers  to  apply  for  a  similar  award  (e.g..  The  Malcolm  Baldrige 
National  Quality  Award).  If  several  companies  report  demonstrable  success  from 
the  approach,  then  OSD  should  undertake  pilot  projects  to  demonstrate  the  use  of 
competition  for  quality  awards  as  part  of  an  acquisition  improvement  effort. 


ACRONYMS 


BILBO 

Built-in  Logic  Block  Observation 

CAD 

Computer-Aided  Design 

CALS 

Computer-aided  Acquisition  and  Logistics  Support 

CATV 

Computer-aided  Timing  Verification 

CUSUM 

Cumulative  Sum  Charts 

DFA 

Design  for  Assembly 

DoD 

Department  of  Defense 

EWMA 

Exponentially  Weighted  Moving  Average 

FMEA 

Failure  Mode  Effects  Analysis 

EVOPS 

Evolutionary  Operations 

FTA 

Fault  Tree  Analysis 

IDA 

Institute  for  Defense  Analyses 

IPDM 

Integrated  Product  Data  Model 

LSSD 

Level-Sensitive  Scan  Design 

NIST 

National  Institute  of  Standards  and  Technology 

OASD(P&L) 

Office  of  the  Assistant  Secretary  of  Defense  for 
Production  and  Logistics 

OSD 

Office  of  the  Secretary  of  Defense 

PDES 

Product  Data  Exchange  Specification 

PQMI 

Process  Quality  Management  Improvement 

QFD 

Quality  Function  Deployment 

QIP 

Qualitv  Improvement  Project 

SPC 

Statistical  Process  Control 

TQM 

Total  Quality  Management 

VOC 

Voice  of  the  Customer 

WSIG 

Weapons  Support  Improvement  Group 
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